CN119938120A - Software management method and system, configuration management platform, and storage medium - Google Patents

Abstract

The application provides a software management method and system, a configuration management platform and a storage medium, wherein the software management method comprises the steps of obtaining a demand document of target software and a data category of the demand document, identifying a target demand contained in the demand document, wherein the target demand contains a number of an upper-layer demand corresponding to the target demand; and establishing a traceability relation between the target demand and the upper-layer demand corresponding to the target demand based on the number of the target demand and the number of the upper-layer demand, and storing the traceability relation between the target demand and the upper-layer demand in a traceability report. According to the technical scheme, the traceability relation between the target requirement and the upper-layer requirement can be automatically established, the traceability relation is stored in the traceability report, and when the requirement of the layer is checked, the upper-layer requirement or the lower-layer requirement can be directly jumped, so that the requirement traceability relation is intuitively presented.

Description

Software management method and system, configuration management platform and storage medium

Technical Field

The application relates to the technical field of software development, in particular to a software management method and device, a management platform, electronic equipment and a storage medium.

Background

With advances and developments in aviation technology, the amount of software used in the onboard systems and equipment of aircraft is increasing. The safety requirements of the on-board software are relatively high due to the particularities of the aircraft. Currently, management of full lifecycle process and yield data for on-board software remains a problem.

Disclosure of Invention

In order to solve the above problems, embodiments of the present application provide a software management method and apparatus, a management platform, an electronic device, and a storage medium.

In a first aspect, an embodiment of the present application provides a software management method, applied to a configuration management platform, where the method includes obtaining a requirement document of target software and a data class of the requirement document, and identifying a target requirement included in the requirement document, where the target requirement includes a number of an upper layer requirement corresponding to the target requirement; and establishing a traceability relation between the target demand and the upper-layer demand corresponding to the target demand based on the number of the target demand and the number of the upper-layer demand, and storing the traceability relation between the target demand and the upper-layer demand in a traceability report.

In combination with the first aspect, a traceability relation between a target demand and an upper demand corresponding to the target demand is established based on the number of the target demand and the number of the upper demand, and the traceability relation between the target demand and the upper demand is stored in a traceability report, which comprises the steps of determining whether the demand identical to the upper demand in number exists in a configuration management platform, determining the demand as the upper demand corresponding to the target demand if the demand identical to the upper demand in number exists in the configuration management platform, establishing the traceability relation between the target demand and the upper demand, and storing the traceability relation between the target demand and the upper demand in the traceability report, wherein the traceability report comprises the number of the target demand and the number of the upper demand, or determining whether the target demand belongs to a derivative demand if the demand does not belong to the derivative demand, and prompting that the traceability relation is not established in the traceability report if the target demand does not belong to the derivative demand.

In combination with the first aspect, the method further comprises the steps of determining whether the target demand is a low-level demand based on the data category, if the target demand is the low-level demand, establishing a traceability relation between the target demand and source codes corresponding to the target demand, and storing the traceability relation between the target demand and the source codes in a traceability report.

In combination with the first aspect, a traceability relation between a target demand and a source code corresponding to the target demand is established, the traceability relation between the target demand and the source code is stored in a traceability report, the traceability relation comprises the steps of associating a source code development library with a configuration management platform, acquiring source code data corresponding to the target demand from the source code development library, establishing the traceability relation between the target demand and the source code based on the source code data, and storing the traceability relation between the target demand and the source code in the traceability report, wherein the source code data is stored in a link mode in the traceability report.

In combination with the first aspect, the method further comprises the steps of acquiring source code data updated for the current time and/or the previous N times when source codes corresponding to the target requirements are updated, and updating the traceability relation between the target requirements and the source codes and storing the traceability relation in a traceability report based on the source code data updated for the current time and/or the previous N times, wherein N is greater than or equal to 1.

In combination with the first aspect, the method further comprises the steps of generating a corresponding test case according to the target requirement, establishing a traceability relation between the test case and the target requirement, storing the traceability relation between the test case and the target requirement in a traceability report, generating a corresponding test procedure according to the test case, establishing the traceability relation between the test procedure and the test case, and storing the traceability relation between the test procedure and the test case in the traceability report, and marking at least one of a lower-layer requirement, the test case or the test procedure with the traceability relation with the target requirement as a questioning state when the target requirement is modified, or marking the test procedure with the traceability relation with the test case as a questioning state when the test case with the traceability relation with the target requirement is modified.

The embodiment of the application provides a software management system which is applied to a configuration management platform and comprises an acquisition module, a determination module and a building module, wherein the acquisition module is used for acquiring a demand document of target software and a data category of the demand document, identifying target demands contained in the demand document, wherein the target demands contain numbers of upper-layer demands corresponding to the target demands, the determination module is used for determining the numbers of the target demands based on the data category and a preset demand numbering rule, and the building module is used for building a traceability relation between the target demands and the upper-layer demands corresponding to the target demands based on the numbers of the target demands and the numbers of the upper-layer demands, and storing the traceability relation between the target demands and the upper-layer demands in a traceability report.

The embodiment of the application provides a configuration management platform, which comprises a software development module, wherein the software development module comprises a traceable report, the traceable report stores a traceable relation between requirements and/or a traceable relation between lower-layer requirements and source codes, the traceable relation between the requirements is generated through the steps of obtaining a requirement document of target software and a data category of the requirement document, identifying a target requirement contained in the requirement document, wherein the target requirement contains a serial number of an upper-layer requirement corresponding to the target requirement, determining the serial number of the target requirement based on the data category and a preset requirement serial number rule, establishing the traceable relation between the target requirement and the upper-layer requirement corresponding to the target requirement based on the serial number of the target requirement and the serial number of the upper-layer requirement, and storing the traceable relation between the target requirement and the upper-layer requirement in the traceable report.

In combination with the third aspect, the format of the requirement document is kept consistent when the requirement document is imported or exported from the configuration management platform, and/or the target requirements contained in the requirement document can be identified in batches.

In a fourth aspect, an embodiment of the present application provides an electronic device, including a processor, and a memory, where the memory is connected to the processor, and the memory is configured to store a computer program, and the computer program implements the software management method described above when executed by the processor.

In a fifth aspect, an embodiment of the present application provides a storage medium, where a computer program is stored, where the computer program, when executed by a processor, implements the software management method described above.

In a sixth aspect, an embodiment of the present application provides a computer program product, including computer program instructions, which when executed by a processor, implement the software management method described above.

Through the technical scheme, the traceability relation between the target requirement and the upper layer requirement is automatically established, the manual work of tracing the requirements one by one is omitted, and traceability errors can be avoided. In addition, the traceability relation is stored in the traceability report, and when the requirement of the layer is checked, the requirement of the upper layer or the lower layer can be directly jumped, so that the requirement traceability relation is intuitively presented. In addition, batch identification of the demands can be realized, errors possibly generated during manual identification of the demands are reduced, time for manually identifying the demands is shortened, and efficiency is improved. In addition, the target demands can be numbered according to the data types and the preset demand numbering rules, and the manual numbering work one by one is omitted.

Drawings

Fig. 1a is a flowchart of a software management method according to an embodiment of the application.

FIG. 1b is a diagram illustrating a trace back relationship between requirements and between lower level requirements and source code.

FIG. 2 is a flowchart of a method for establishing a retrospective relationship between a target demand and an upper-level demand according to an embodiment of the present application.

Fig. 3 is a flowchart of a method for establishing a traceability relationship between a target demand and a source code according to an embodiment of the present application.

Fig. 4a is a flowchart illustrating a method for establishing a traceability relationship between a target demand and a source code according to an embodiment of the present application.

FIG. 4b is a flowchart illustrating a trace back relationship between the update source code and the low-level requirements according to an embodiment of the present application.

Fig. 5 is a block diagram of a software management apparatus according to an embodiment of the present application.

Fig. 6 is a schematic diagram of a man-machine interaction interface according to an embodiment of the application.

FIG. 7 is a schematic diagram of an item library architecture according to an embodiment of the present application.

Fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

In the airworthiness certification of software, traceable data between software requirements and between requirements and source codes is a material of particular concern in airworthiness certification. However, at present, in the field of aviation, two management modes of software life cycle data exist, one management mode is that a software life cycle management platform consistent with an airplane-level research and development management platform is adopted, a scheme suitable for software airworthiness is not proposed, the traceability relationship between the software requirement and the source code cannot be intuitively embodied, and traceability errors between the requirement and the source code are caused. The second management mode is to construct a management platform suitable for software, and although a mode of software airworthiness authentication is provided, a database establishment mode, a traceability relation establishment mode and the like are not explicitly provided, and the demand management platform needs to integrate a DOORS scheme, so that traceability relation of all demands and presentation of all traceability data cannot be realized in one platform, and traceability errors may be caused.

In view of the above technical problems, an embodiment of the present application provides a software management method, which is applied to a configuration management platform, and the method includes obtaining a requirement document of target software and a data category of the requirement document, identifying a target requirement included in the requirement document, the target requirement including a number of an upper layer requirement corresponding to the target requirement, determining the number of the target requirement based on the data category and a preset requirement numbering rule, establishing a traceability relation between the target requirement and the upper layer requirement corresponding to the target requirement based on the number of the target requirement and the number of the upper layer requirement, and storing the traceability relation between the target requirement and the upper layer requirement in a traceability report. In the embodiment of the application, the traceability relation between the target requirement and the upper layer requirement is automatically established, the manual work of tracing the requirements one by one is omitted, and the traceability error can be avoided. In addition, the traceability relation is stored in the traceability report, and when the requirement of the layer is checked, the requirement of the upper layer or the lower layer can be directly jumped, so that the requirement traceability relation is intuitively presented.

Fig. 1a is a flowchart of a software management method according to an embodiment of the application. The method is applied to a configuration management platform, as shown in fig. 1a, and comprises the following steps.

In general, the configuration management platform stores various documents of software, when the configuration management platform is used for compiling the documents, the format of the documents cannot be adjusted, so that the document format of the configuration management platform is not matched with a company document template, and when the documents are imported or exported, the consistency of the documents cannot be ensured. In the embodiment of the application, the document template rule matched with the company document template is designed in the configuration management platform, and the default template is embedded into the configuration management platform (specifically, the document is secondarily developed in the functions of document import and document editing provided by the configuration management platform, and the company template format is embedded), so that when the document is imported into the configuration management platform after being compiled under a document line, the format corresponding to the content is read and identified while the document content is read, so that the format embedded in the platform is matched with the format corresponding to the document content, the format is kept unchanged, and when the document is exported from the configuration management platform, the format is kept not covered by the default format of the platform, and thus, the consistency among the documents is kept when the document related to software is delivered. That is, in the embodiment of the present application, when the demand document is imported or exported from the configuration management platform, the format of the demand document is kept consistent, so that the on-line and off-line development work selectivity of the configuration management platform can be realized. In addition, the target requirements contained in the requirement document can be identified in batches, and the target requirements and the requirement document do not need to be managed separately, so that the readability of the requirements is improved.

In addition, in determining the document template rules, the format of the requirements is specified for identification of the requirements. FIG. 1b is a diagram illustrating a trace back relationship between requirements and between lower level requirements and source code. As shown in FIG. 1b, the requirements include system requirements, high-level requirements, low-level requirements. The system requirement is a general term for describing various requirements of functions, performances, safety, operation and the like which are required to be realized by the whole airborne software. The system requirements are the basis for software development, which defines the overall goals and requirements that the software must meet. Multiple high-level demands can be resolved according to system demands. Namely, there is a retrospective relationship between system requirements and higher-level requirements. The high-level requirements are the functions and capabilities that the software should possess. In particular, high-level requirements provide specific goals and tasks for software development. Multiple lower-level requirements can be resolved according to each higher-level requirement. Namely, there is a retrospective relationship between the high-level demand and the low-level demand. Low-level requirements in software development generally refer to functional requirements (e.g., software functions implemented in a product by a developer, which functions are required to meet high-level requirements) or detailed design requirements (e.g., architectural design of a system, module partitioning, interface definition, etc.). The low-level requirements provide specific methods and means for software development to achieve the high-level requirements. The source code is opened according to the low-level requirements. I.e. there is a retrospective relationship between the low level requirements and the source code. Source code is a specific means of implementing system requirements, high-level requirements, and low-level requirements in software development. When the demand document is imported, the demand document of the system demand is imported, and then the demand document of the higher-level demand and the demand document of the lower-level demand are imported in sequence, so that when the demand document is imported, the upper-level demand of the target demand contained in the demand document is imported into the configuration management platform. In the embodiment of the present application, the upper-level requirement of the target requirement refers to the upper-level requirement having a retrospective relationship with the target requirement. Therefore, the traceability between the demands can be realized only by establishing the traceability relation between the target demands and the upper-layer demands, for example, when the upper-layer demands are imported, the system demands are imported into the configuration management platform, the traceability relation between the upper-layer demands and the system demands can be established, and when the lower-layer demands are imported, the upper-layer demands are imported into the configuration management platform, and the traceability relation between the lower-layer demands and the upper-layer demands can be established.

Step S110, a requirement document of the target software and a data category of the requirement document are obtained, and target requirements contained in the requirement document are identified.

When a user imports a demand document into the configuration management platform, the user writes the data category in the system background of the configuration management platform. Therefore, after the requirement document is imported into the configuration management platform, the requirement document of the target software and the data category of the requirement document can be directly acquired. In an embodiment of the present application, the data category includes at least one of a high-level requirement and a low-level requirement.

In the prior art, the requirement and the requirement related files (including description and explanation of the requirement, summary of the system and software, design of the software and the like) are generally separately managed, and in the embodiment of the application, the requirement and the requirement related files are not required to be separately managed, and the requirement document comprises the requirement and the requirement related files. After the requirement document is acquired, the target requirement contained in the requirement document can be identified according to the format of the requirement. In the embodiment of the application, the requirement document comprises a plurality of target requirements of the same hierarchy, namely, the target requirements in the same requirement document belong to the same hierarchy, for example, the requirement document comprises a plurality of high-level requirements or a plurality of low-level requirements. Therefore, batch identification of the demands can be realized, errors possibly generated during manual identification of the demands are reduced, the time for manual identification of the demands is shortened, and the efficiency is improved. It should be noted that, in the embodiment of the present application, the target requirement includes a high-level requirement or a low-level requirement. Since the system requirements do not need to be traced upwards, the target requirements do not include the system requirements.

In the embodiment of the present application, the target requirement includes the number of the upper layer requirement corresponding to the target requirement. The upper-level requirements corresponding to the target requirements refer to upper-level requirements having a retrospective relationship with the target requirements. When the demand document is compiled, the number of the upper demand is required to be filled in the target demand, and when the demand is identified, the number of the upper demand corresponding to the target demand can be identified. Table 1 shows a format of the requirements, as shown in Table 1, the requirements include upper layer requirement IDs (i.e. numbers of upper layer requirements), before the requirement document is imported, the user needs to fill in the upper layer requirement IDs in each requirement, and when the requirement document is imported, the upper layer requirement IDs corresponding to the target requirements are automatically extracted. As shown in Table 1, the requirements also include requirements ID, type of requirements, whether and reason for derivatization, authentication mode, security requirements, description of requirements, description, etc. It will be appreciated that the format and content of the requirements shown in table 1 are merely exemplary, and those skilled in the art can adjust the format and content of the requirements according to actual requirements.

Table 1 exemplary formats for demand

Step S120, determining the number of the target requirement based on the data category and a preset requirement number rule.

In the embodiment of the application, different requirement numbering rules are set for requirements of different layers in the configuration management platform, namely, the requirement numbering rules of requirements of different data types are different. Since the demand document may contain a plurality of target demands, the plurality of target demands in the demand document are numbered one by one according to the data category and the demand numbering rule corresponding to the data category, and the numbers are written into the target demands (i.e., the positions of the demand IDs in table 1). For example, if the data class is a High-level requirement, the requirement numbering rule is software name+HLR+serial number, where HLR is an abbreviation for High-level requirement (High-level requirement). If the data category is a low-level demand, the demand numbering rule is software name+LLR+serial number, wherein the LLR is Lower-level requirement (low-level demand) abbreviation. And numbering a plurality of high-level demands in the demand document one by one according to the demand numbering rule. In the embodiment of the application, each requirement needs to be ensured to have a unique requirement number, and after any requirement is deleted, the requirement number of the deleted requirement is not used any more, so that data errors are avoided.

Step S130, based on the number of the target demand and the number of the upper-layer demand, a traceability relation between the target demand and the upper-layer demand corresponding to the target demand is established, and the traceability relation between the target demand and the upper-layer demand is stored in the traceability report.

In the embodiment of the application, the traceability relation between the target demand and the upper demand is established based on the number of the upper demand and is stored in the traceability report. Optionally, in the retrospective report, the upper-layer requirement is stored in the upper-layer requirement ID of the requirement in a link form, and when the user clicks the upper-layer requirement ID, the user can directly jump to the upper-layer requirement, so that the process of realizing the requirement is intuitively presented. A specific description of establishing the retrospective relationship between the target requirement and the upper layer requirement may be referred to fig. 2, and will not be repeated here.

In the embodiment of the application, the traceability relation between the target requirement and the upper layer requirement is automatically established, the manual work of tracing the requirements one by one is omitted, and the traceability error can be avoided. In addition, the traceability relation is stored in the traceability report, and when the requirement of the layer is checked, the requirement of the upper layer or the lower layer can be directly jumped, so that the requirement traceability relation is intuitively presented. In addition, batch identification of the demands can be realized, errors possibly generated during manual identification of the demands are reduced, time for manually identifying the demands is shortened, and efficiency is improved. In addition, the target demands can be numbered according to the data types and the preset demand numbering rules, and the manual numbering work one by one is omitted.

FIG. 2 is a flowchart of a method for establishing a retrospective relationship between a target demand and an upper-level demand according to an embodiment of the present application. As shown in fig. 2, the method includes the following steps.

Step S210, determining whether there is a requirement with the same number as the upper layer requirement in the configuration management platform.

In the embodiment of the application, according to the number of the upper layer requirement, whether the requirement which is the same as the number of the upper layer requirement exists is searched in the configuration management platform. If the configuration management platform has the same number as the upper layer requirement, step S220 is performed. In step S220, the requirement is determined as an upper-layer requirement corresponding to the target requirement, a traceability relationship between the target requirement and the upper-layer requirement is established, and the traceability relationship between the target requirement and the upper-layer requirement is stored in the traceability report. The traceability report includes the number of the target demand and the number of the upper layer demand. In the embodiment of the application, the requirement traceability relation can be established in such a way that the number of the upper layer requirement of the target requirement can be seen in the generated traceability report, and after clicking the number of the upper layer requirement, the user can directly jump to the upper layer requirement to look up the content of the upper layer requirement.

Optionally, if there is no requirement with the same number as the upper layer requirement in the configuration management platform, step S230 is performed. In step S230, it is determined whether the target demand belongs to the derivative demand. In the embodiment of the present application, the derived demand refers to a demand without an upper-layer demand, and the derived demand cannot be traced back to the upper-layer demand or the system demand. If the target demand does not belong to the derived demand, step S240 is executed to prompt that the target demand does not establish the traceability relationship in the traceability report. In this case, the upper layer requirement is not imported into the configuration management platform, or the upper layer requirement ID fills in an error, and at this time, the user leaks and supplements the defect in the configuration management platform according to the prompt information, so as to realize the correct tracing of the requirement. If the target demand belongs to the derived demand, step S250 is performed to mark the target demand as the derived demand. Alternatively, information pertaining to the derivative requirement may be filled in a corresponding position in the requirement shown in table 1, for example, contents such as "yes", "derivative requirement" and the like may be filled in.

In the embodiment of the application, the upper-layer requirements corresponding to the target requirements are determined according to the numbers of the upper-layer requirements, the traceability relation between the target requirements and the upper-layer requirements is established, and if the requirements which are the same as the numbers of the upper-layer requirements do not exist and the requirements do not belong to the derivative requirements, the traceability relation is prompted in the traceability report that the target requirements do not establish the traceability relation, so that the reasons can be searched and the correct traceability of the requirements can be completed.

In the prior art, the file name of the source code corresponding to the low-level requirement is manually filled in, and cannot be traced back to a detailed code segment or code line, namely, the tracing relation between the requirement (low-level requirement) and the source code cannot be intuitively embodied. In the embodiment of the application, the traceability relation between the demand and the source code is established, and the source code data is stored in the traceability report in a linked mode, so that the efficiency of source code examination and verification is improved. As particularly shown in fig. 3.

Fig. 3 is a flowchart of a method for establishing a traceability relationship between a target demand and a source code according to an embodiment of the present application. As shown in fig. 3, the method includes the following steps.

In step S310, it is determined whether the target demand is a low-level demand based on the data category.

Because there is a traceability relationship between the low-level requirements and the source code, before the traceability relationship between the target requirements and the source code is established, it is necessary to determine whether the requirements are low-level requirements. If the target demand is a low-level demand, step S320 is performed.

Step S320, a traceability relation between the target demand and the source code corresponding to the target demand is established, and the traceability relation between the target demand and the source code is stored in a traceability report. Because the target requirement is stored in the configuration management platform and the source code is stored in the source code development library, the external interface of the configuration management platform and the external interface of the source code development library are required to be associated through development application, so that the source code data are read in the source code development library and transmitted to the configuration management platform in a linked mode, and the traceability relationship between the target requirement (namely, the low-level requirement) and the source code is established. As particularly shown in fig. 4 a.

In the embodiment of the application, the association and data sharing of the configuration management platform and the source code development library are realized through secondary development, so that the traceability relationship between the target requirement (namely the low-level requirement) and the source code is established and stored in the traceability report. When clicking the link of the source code data in the trace back report, the link can be directly jumped to the code segment or the code line of the source code corresponding to the low-level requirement in the source code development library, thereby realizing the visual link relation between the low-level requirement and the source code and improving the efficiency of source code examination and verification.

Fig. 4a is a flowchart illustrating a method for establishing a traceability relationship between a target demand and a source code according to an embodiment of the present application. As shown in fig. 4a, the method comprises the following steps.

Step S410, associating the source code development library with the configuration management platform.

In the embodiment of the application, the external interface of the source code development library is associated with the external interface of the configuration management platform through development application, so that the data can be read from the source code development library and transmitted to the configuration management platform.

Step S420, source code data corresponding to the target requirement is obtained from a source code development library.

In the embodiment of the application, the source code data corresponding to the target demand can be directly read from the source code development library, for example, the source code corresponding to the target demand, the data required for establishing the target demand and tracing the source code, and the like. The read source code data is then converted into a linked form for transmission to the configuration management platform. In an embodiment of the present application, the file name of the source code and the line number of the source code may be read out on a link, and the link is in the form of http://192.168. Xx/xx item/. The source code file name #l126, where L126 refers to the line number of the source code.

Step S430, based on the source code data, a traceability relation between the target demand and the source code is established, and the traceability relation between the target demand and the source code is stored in a traceability report.

In the embodiment of the application, the source code data is stored in the traceability report in a link mode, and when the link of the source code data is clicked, the source code data can jump to the code section of the source code corresponding to the target requirement in the source code development library, so that the traceability relation between the low-level requirement and the source code can be intuitively embodied. In the embodiment of the application, the bidirectional tracing from the system requirement to the high-level requirement, the bidirectional tracing from the high-level requirement to the low-level requirement and the bidirectional tracing from the low-level requirement to the source code can be realized, the complete tracing relation is established, and the full life cycle data of software development can be conveniently checked.

In the embodiment of the application, when the source code corresponding to the target demand is updated, the source code data updated for the current time and/or the previous N times is obtained, and the traceability relation between the target demand and the source code is updated and stored in a traceability report based on the source code data updated for the current time and/or the previous N times, wherein (N is greater than or equal to 1). Specifically, when the source code of the source code database is updated, an application can be triggered, the application automatically reads the source code data updated this time and/or the last N times and transmits the source code data to the configuration management platform, the lower-layer requirement corresponding to the updated source code data is searched in the configuration management platform, and a link of the updated source code data, namely the traceability relation between the updated target requirement and the source code, is filled in a code work item (for example, in a traceability report) corresponding to the lower-layer requirement. In the embodiment of the application, when the source code is updated, the link of the source code data can be updated in the corresponding low-layer requirement, so that the accuracy and timeliness of tracing are improved.

FIG. 4b is a flowchart illustrating a trace back relationship between the update source code and the low-level requirements according to an embodiment of the present application. The flow may be implemented by a developed application. The method specifically comprises the following steps of firstly, determining whether source codes are updated. If the source code is updated, an external interface function of the source code development library is called, first information (namely updated source code data) output by the external interface function is recorded, then recorded second information (namely original source code data) is queried one by one in a configuration management platform, recording information corresponding to the first information and low-layer requirements are determined, the external interface function of the configuration management platform is called, the updated source code data is converted into hyperlinks and is inserted into code work items corresponding to the low-layer requirements, and then the recorded information is cleared. It will be appreciated that the process is monitored continuously, for example, every 5 s.

The method further comprises the steps of generating a corresponding test case according to the target requirement, establishing a traceability relation between the test case and the target requirement, storing the traceability relation between the test case and the target requirement in a traceability report, generating a corresponding test procedure according to the test case, establishing the traceability relation between the test procedure and the test case, and storing the traceability relation between the test procedure and the test case in the traceability report. That is, the embodiment of the application can realize the traceability relationship from the system requirement to the high-level requirement to the low-level requirement to the source code, the traceability relationship from the high-level requirement to the test case to the test procedure, and the traceability relationship from the low-level requirement to the test case to the test procedure.

Optionally, when the target demand is modified, at least one of the lower-layer demand, the test case or the test procedure which has a traceability relation with the target demand is marked as a questioning state, or when the test case which has a traceability relation with the target demand is modified, the test procedure which has a traceability relation with the test case is marked as a questioning state. Therefore, the time for manually analyzing the influence domain (in the configuration management platform, the influence domain refers to the influence range of a certain data change on the data of a system, a product or other configuration items) can be saved, and the probability that the modification of the certain data affects other data due to the fact that the influence domain is not analyzed in place is reduced, but the other data are not synchronously modified is reduced.

In a second aspect, an embodiment of the present application provides a software management system, which is applied to a configuration management platform.

Fig. 5 is a block diagram of a software management system according to an embodiment of the present application. As shown in fig. 5, the software management system 500 includes an acquisition module 510, a determination module 520, and a setup module 530.

The obtaining module 510 is configured to obtain a requirement document of the target software and a data category of the requirement document, and identify a target requirement included in the requirement document, where the target requirement includes a number of an upper layer requirement corresponding to the target requirement.

The determining module 520 is configured to determine the number of the target requirement based on the data class and a preset requirement numbering rule.

The establishing module 530 is configured to establish a traceability relationship between the target demand and an upper demand corresponding to the target demand based on the number of the target demand and the number of the upper demand, and store the traceability relationship between the target demand and the upper demand in a traceability report.

Optionally, the establishing module 530 is further configured to determine whether a requirement with the same number as the upper layer requirement exists in the configuration management platform, determine the requirement as an upper layer requirement corresponding to the target requirement if the requirement with the same number as the upper layer requirement exists in the configuration management platform, establish a traceability relationship between the target requirement and the upper layer requirement, and store the traceability relationship between the target requirement and the upper layer requirement in a traceability report, where the traceability report includes the number of the target requirement and the number of the upper layer requirement, or determine whether the target requirement belongs to a derivative requirement if the requirement with the same number as the upper layer requirement does not exist in the configuration management platform, and prompt that the traceability relationship is not established in the traceability report if the target requirement does not belong to the derivative requirement.

Optionally, the establishing module 530 is further configured to determine whether the target requirement is a low-level requirement based on the data category, and if the target requirement is the low-level requirement, establish a traceability relationship between the target requirement and a source code corresponding to the target requirement, and store the traceability relationship between the target requirement and the source code in the traceability report.

Optionally, the establishing module 530 is further configured to associate the source code development library with the configuration management platform, obtain source code data corresponding to the target requirement from the source code development library, establish a traceability relationship between the target requirement and the source code based on the source code data, and store the traceability relationship between the target requirement and the source code in a traceability report, where the source code data is stored in a linked form.

Optionally, the establishing module 530 is further configured to obtain source code data updated this time and/or N times before when the source code corresponding to the target demand is updated, update a traceability relationship between the target demand and the source code based on the source code data updated this time and/or N times before and store the traceability relationship in the traceability report, where N is greater than or equal to 1.

Optionally, the establishing module 530 is further configured to generate a corresponding test case according to the target requirement, establish a traceability relationship between the test case and the target requirement, and store the traceability relationship between the test case and the target requirement in the traceability report, generate a corresponding test procedure according to the test case, establish the traceability relationship between the test procedure and the test case, and store the traceability relationship between the test procedure and the test case in the traceability report. The establishing module 530 is further configured to mark at least one of a lower-level requirement, a test case, or a test procedure having a traceable relation with the target requirement as a questioning state when the target requirement is modified, or mark a test procedure having a traceable relation with the test case as a questioning state when the test case having a traceable relation with the target requirement is modified.

The specific working principle and benefits of the software management device provided by the embodiment of the present application are similar to those of the software management method provided by the embodiment of the present application, and will not be described here again.

In a third aspect, the embodiment of the present application further provides a configuration management platform, where the configuration management platform can accurately and efficiently manage configuration information of a product. The configuration management platform comprises a software development module, wherein the software development module comprises a traceable report, the traceable report stores traceable relations between requirements and/or traceable relations between lower-layer requirements and source codes, the traceable relations between the requirements and the requirements are generated through the steps of obtaining a requirement document of target software and a data category of the requirement document, identifying target requirements contained in the requirement document, wherein the target requirements contain numbers of upper-layer requirements corresponding to the target requirements, determining the numbers of the target requirements based on the data category and a preset requirement numbering rule, establishing the traceable relations between the target requirements and the upper-layer requirements corresponding to the target requirements based on the numbers of the target requirements and the numbers of the upper-layer requirements, and storing the traceable relations between the target requirements and the upper-layer requirements in the traceable report.

Optionally, the format of the requirements document remains consistent when importing or exporting the configuration management platform. In this way, the selectivity of the development work on-line and off-line of the configuration management platform can be realized. In addition, the target requirements contained in the requirement document can be identified in batches, and the target requirements and the requirement document do not need to be managed separately, so that the readability of the requirements is improved.

In order to facilitate understanding of the technical scheme of the application, a project library is taken as an example to describe the software development work of the configuration management platform.

Firstly, according to the project condition, a project library is established, wherein the project library comprises a plurality of functional modules. And designing a man-machine interaction interface, taking the item library as a selectable item, when a plurality of items exist, clicking and selecting the item library by a user according to actual conditions, and displaying all modules in the item library on the man-machine interaction interface.

In order to realize the cooperative work of multiple persons in the project group and the internal examination requirement of the company, a configuration management platform server is accessed to a local area network of the company, so that the access rights of members in the company are ensured. After a user with authority logs in, a project library can be selected on the man-machine interaction interface, each module can be checked on the man-machine interaction interface after selection, when a newly built document or a document is imported, a corresponding module is selected on the man-machine interaction interface, the document can be stored in the corresponding module, and when the user is checked internally, the data stored in each module are checked one by one through the man-machine interaction interface, so that the integrity of each process data can be judged. Exemplary, a schematic diagram of a man-machine interface is shown in fig. 6, and a user may select different project libraries by clicking a drop-down box beside a project name, and may enter a module by clicking a drop-down option beside each module in the project. According to the project library planning mode, a user can respectively check the states of the data in each module of the project library, so that the current research and development progress can be known, and in which life cycle process, the project group members can check the integrity of the life cycle data conveniently. In the embodiment of the application, the project library comprises a software planning module, a software development module, a software verification module, a software quality assurance module, a software configuration management module and a qualification approval module, and is particularly shown in fig. 7.

Optionally, the software planning module is used for supporting activities of the software planning process and managing lifecycle data generated by the planning process, and provides a human-machine interface for software project team members to import or edit software planning related files online from offline. Illustratively, at least the data shown in Table 2 is included in the software planning module.

Table 2 software planning module data

Sequence number	Data
		1	Software qualification plan
2	Software development planning
		3	Software verification plan
4	Software quality assurance plan
		5	Software configuration management plan
6	Software requirement standard
		7	Software design criteria
8	Software coding standard
		9	Inspection sheet template for all life cycle data

Optionally, the software development module comprises a software requirement unit, a software design unit, a software code unit, a software integration unit and the like for completely embodying the software development process. The user imports the file or newly built file in different units according to the different contents, such as the file of the software high-level requirement selects the software requirement unit, the file of the software low-level requirement and the software architecture design selects the software design unit. Illustratively, the software development module includes at least the data shown in Table 3. The system requirement, the software high-level requirement, the software low-level requirement and the traceability relation report of the source code are stored in the software development module, and a user can directly click to check the traceability report.

TABLE 3 software development Module data

Optionally, in order to clearly show the verification work, the software verification module includes related contents of software test and review analysis, the software verification module includes a verification evidence unit, and the software verification unit mainly stores software test cases and test procedures, and stores data such as review checklists, review disciplines, test results, analysis reports and the like of all data. Illustratively, the software validation module includes at least the data shown in Table 4. The software verification module stores a traceability report between the test case, the test procedure and the requirement, and the user can click to check.

Table 4 software verification Module data

Sequence number	Data
		1	Software test case
2	Software testing protocol
		3	Software test procedure execution record
4	Inspection sheets and review summary of each document
		5	Analysis report
6	Retrospective reporting between test cases, test protocols and requirements

Optionally, the software quality assurance module provides the software quality assurance engineer with space to store quality assurance process data to import or edit software quality assurance related files online from offline.

Optionally, the software configuration management module provides the software configuration management engineer with space to store configuration management process data to import or edit software configuration management related files online from offline.

Optionally, the qualification module is used for storing all information interacted with the office party in the project proceeding process.

Next, an electronic device according to an embodiment of the present application is described with reference to fig. 8. Fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

As shown in fig. 8, the electronic device 800 includes one or more processors 801 and memory 802.

The processor 801 may be a Central Processing Unit (CPU) or other form of processing unit having data processing and/or instruction execution capabilities and may control other components in the electronic device 800 to perform desired functions.

Memory 802 may include one or more computer program products that may include various forms of computer-readable storage media, such as volatile memory and/or non-volatile memory. The volatile memory may include, for example, random Access Memory (RAM) and/or cache memory (cache), and the like. The non-volatile memory may include, for example, read Only Memory (ROM), hard disk, flash memory, and the like. One or more computer program instructions may be stored on the computer readable storage medium that can be executed by the processor 801 to implement the software management methods and/or other desired functions of the various embodiments of the present application described above. Various content, such as including a requirements document, a requirement, and the like, may also be stored in the computer-readable storage medium.

In one example, electronic device 800 may also include input 803 and output 804 devices interconnected by a bus system and/or other forms of connection mechanisms (not shown).

The input device 803 may include, for example, a keyboard, a mouse, and the like.

The output device 804 may output various information to the outside, including a trace back report between the requirements, a trace back report directly between the requirements and the source code, and the like. The output device 804 may include, for example, a display, speakers, a printer, and a communication network and remote output devices connected thereto, etc.

Of course, only some of the components of the electronic device 800 that are relevant to the present application are shown in fig. 8 for simplicity, components such as buses, input/output interfaces, etc. are omitted. In addition, the electronic device 800 may include any other suitable components depending on the particular application.

In addition to the methods and apparatus described above, embodiments of the application may also be a computer program product comprising computer program instructions which, when executed by a processor, cause the processor to perform the steps in the software management method according to the various embodiments of the application described above in this specification.

The computer program product may write program code for performing operations of embodiments of the present application in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server.

Furthermore, embodiments of the present application may also be a computer-readable storage medium, on which computer program instructions are stored, which when being executed by a processor, cause the processor to perform the steps in the software management method according to the various embodiments of the present application described in the present specification.

The computer readable storage medium may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may include, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of a readable storage medium include an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The basic principles of the present application have been described above in connection with specific embodiments, but it should be noted that the advantages, benefits, effects, etc. mentioned in the present application are merely examples and not intended to be limiting, and these advantages, benefits, effects, etc. are not to be construed as necessarily possessed by the various embodiments of the application. Furthermore, the specific details disclosed herein are for purposes of illustration and understanding only, and are not intended to be limiting, as the application is not necessarily limited to practice with the above described specific details.

The block diagrams of the devices, apparatuses, devices, systems referred to in the present application are only illustrative examples and are not intended to require or imply that the connections, arrangements, configurations must be made in the manner shown in the block diagrams. As will be appreciated by one of skill in the art, the devices, apparatuses, devices, systems may be connected, arranged, configured in any manner. Words such as "including," "comprising," "having," and the like are words of openness and mean "including but not limited to," and are used interchangeably therewith. The terms "or" and "as used herein refer to and are used interchangeably with the term" and/or "unless the context clearly indicates otherwise. The term "such as" as used herein refers to, and is used interchangeably with, the phrase "such as, but not limited to.

It is also noted that in the apparatus, devices and methods of the present application, the components or steps may be disassembled and/or assembled. Such decomposition and/or recombination should be considered as equivalent aspects of the present application.

The previous description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects without departing from the scope of the application. Thus, the present application is not intended to be limited to the aspects shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

The foregoing description has been presented for purposes of illustration and description. Furthermore, this description is not intended to limit embodiments of the application to the form disclosed herein. Although a number of example aspects and embodiments have been discussed above, a person of ordinary skill in the art will recognize certain variations, modifications, alterations, additions, and subcombinations thereof.

Claims (10)

1. A software management method, applied to a configuration management platform, the method comprising:

Acquiring a demand document of target software and a data category of the demand document, and identifying a target demand contained in the demand document, wherein the target demand contains a number of an upper-layer demand corresponding to the target demand;

determining the number of the target demand based on the data category and a preset demand number rule;

and establishing a traceability relation between the target demand and the upper demand corresponding to the target demand based on the number of the target demand and the number of the upper demand, and storing the traceability relation between the target demand and the upper demand in a traceability report.

2. The method according to claim 1, wherein the establishing a traceability relation between the target demand and an upper-layer demand corresponding to the target demand based on the number of the target demand and the number of the upper-layer demand, and storing the traceability relation between the target demand and the upper-layer demand in a traceability report, includes:

determining whether the requirements with the same number as the upper-layer requirements exist in the configuration management platform;

If the configuration management platform has the same requirement as the upper-layer requirement, determining the requirement as an upper-layer requirement corresponding to the target requirement, establishing a traceability relation between the target requirement and the upper-layer requirement, and storing the traceability relation between the target requirement and the upper-layer requirement in the traceability report, wherein the traceability report comprises the number of the target requirement and the number of the upper-layer requirement, or

And if the target demand does not belong to the derivative demand, prompting that the target demand does not establish a traceability relation in the traceability report.

3. The method as recited in claim 1, further comprising:

determining whether the target demand is a low-level demand based on the data category;

If the target demand is a low-level demand, establishing a traceability relation between the target demand and a source code corresponding to the target demand, and storing the traceability relation between the target demand and the source code in the traceability report.

4. The method of claim 3, wherein the establishing a traceability relationship between the target demand and a source code corresponding to the target demand and storing the traceability relationship between the target demand and the source code in the traceability report comprises:

Associating a source code development library with the configuration management platform;

Acquiring source code data corresponding to the target requirement from the source code development library;

and establishing a traceability relation between the target demand and the source code based on the source code data, and storing the traceability relation between the target demand and the source code in a traceability report, wherein the source code data is stored in a link form in the traceability report.

5. The method as recited in claim 4, further comprising:

when the source code corresponding to the target requirement is updated, acquiring the source code data updated for the current time and/or the previous N times;

Updating the traceability relation between the target demand and the source code based on the source code data updated this time and/or the previous N times and storing the traceability relation in the traceability report, wherein N is greater than or equal to 1.

6. The method as recited in claim 1, further comprising:

generating a corresponding test case according to the target demand, establishing a traceability relation between the test case and the target demand, and storing the traceability relation between the test case and the target demand in a traceability report;

Generating a corresponding test procedure according to the test case, establishing a traceability relation between the test procedure and the test case, and storing the traceability relation between the test procedure and the test case in the traceability report;

The method further comprises the step of marking at least one of a lower-layer requirement, a test case or a test procedure which has a traceability relation with the target requirement as a questioning state when the target requirement is modified, or marking the test procedure which has a traceability relation with the test case as a questioning state when the test case which has a traceability relation with the target requirement is modified.

7. A software management system for use with a configuration management platform, the software management system comprising:

The system comprises an acquisition module, a storage module and a storage module, wherein the acquisition module is used for acquiring a demand document of target software and a data category of the demand document, and identifying a target demand contained in the demand document, wherein the target demand contains a serial number of an upper-layer demand corresponding to the target demand;

the determining module is used for determining the number of the target requirement based on the data category and a preset requirement number rule;

the establishing module is used for establishing a traceability relation between the target demand and the upper demand corresponding to the target demand based on the number of the target demand and the number of the upper demand, and storing the traceability relation between the target demand and the upper demand in a traceability report.

8. A configuration management platform, comprising:

The software development module comprises a traceability report, wherein the traceability report stores traceability relation between requirements and/or traceability relation between low-level requirements and source codes, and the traceability relation between the requirements is generated through the following steps:

Acquiring a demand document of target software and a data category of the demand document, and identifying a target demand contained in the demand document, wherein the target demand contains a number of an upper-layer demand corresponding to the target demand;

determining the number of the target demand based on the data category and a preset demand number rule;

and establishing a traceability relation between the target demand and the upper demand corresponding to the target demand based on the number of the target demand and the number of the upper demand, and storing the traceability relation between the target demand and the upper demand in the traceability report.

9. The configuration management platform according to claim 8, wherein the format of the requirement document is kept consistent when the requirement document is imported or exported from the configuration management platform, and/or the target requirement contained in the requirement document can be identified in batches.

10. A storage medium having stored thereon a computer program which, when executed by a processor, implements the software management method according to any of claims 1 to 6.