JP2003122570A - Document and program management method in development of software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To manage, as objects, products created in the development of software, causes of changes, and information relevant to tests, and manage a relation between the objects. SOLUTION: The contents of change and the causes of the change of each document and program are managed in association with each other for design documents showing the contents of design, test documents and programs showing the contents of tests prepared in the development of software. Also, the contents of change of the design documents showing the relation between the contents of the tests and troubles, the troubles, and the contents of the design for products thereby and test documents and program are managed in association with each other in the test stages of the development of the software. The state of execution of the tests, the results thereof, and the change of the program thereby are managed, re-tests are performed automatically for the modified troubles, and the result are checked. Also the state of progress of an entire development project is understood. In addition, a diversion history and a change reflected history are managed.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to management of electronic files constituting documents and programs created in software development, file management by conventional directory division, and conventional database (list).
In addition to management of change reasons in the past, change management using conventional version management tools, N-to-N with individual documents and programs
It relates to a method of managing documents and programs in software development for supporting relationship management of change reasons corresponding to, and history management / reflection support utilizing the reason.

[0002]

2. Description of the Related Art Conventionally, as a change content management method for individual files constituting a document, for example, there is one disclosed in Japanese Patent Application Laid-Open No. 5-81000. When a document change occurs, this compares the document before and after the change, and the changed part (difference)
Is extracted and the revision contents of the document file are added while saving the difference data as needed.

[0003]

However, in the above-mentioned conventional method, the user can perform "version management / change management of individual document files", but "why has it been changed" and "what is the range of its influence?" It is not possible to know the situation such as "How much verification testing is needed for that?"

Further, in software development, it is difficult to clarify "execution of retesting when a failure occurs at the test stage" and "understanding of development progress" because of human origin. Again, it is desirable to automate this by managing documents and programs themselves, status management, and linked management with the reason for changes.

The present invention has been made in view of the above points, and includes products (documents, programs, etc.) created in software development, change factors (points pointed out in design reviews, failure information at the time of testing, etc.), It is intended to provide a document and program management method in software development that can manage information related to tests (test items, test results, etc.) as objects and manage the relationship between each object. .

[0006]

A document and program management method in software development according to the present invention relates to a design document indicating design content created in software development, a test document indicating test content, and a program. It is characterized in that the contents of changes of individual documents and programs and the reasons for the changes are managed in cooperation with each other.

In the software development test stage, the relationship between the test content and the fault, the design document indicating the fault and the design content resulting from the fault, the test document indicating the test content, and the program change content are linked. It is characterized by managing by doing.

In addition, in the software development test stage, the test execution status and its result, and the program change resulting therefrom are managed, and the retested fault is automatically retested to confirm the result. It is characterized by.

Further, the present invention is characterized in that the design document showing the design contents created in software development, the test document showing the test contents, and the production status of the program are grasped to grasp the progress situation of the whole development project. Is.

Further, a design document showing design contents created in parallel development of a plurality of similar software, a test document showing test contents, and an individual document and a diversion history / change reflection history of the program are stored for each program. It is characterized by managing.

[0011]

BEST MODE FOR CARRYING OUT THE INVENTION In the method of managing documents and programs in software development according to the present invention, products (documents and programs etc.) created in software development, change factors (points pointed out in a design review, at the time of testing) The failure information of), information related to the test (test items, test results, etc.) are managed as objects, and the relationship between each object is managed. Each object is centrally managed on the tool, and the minimum information is "information indicating the type of object (product created in software development, change factor, information related to testing, etc.)" and "unique object name". (Document name, program name, change factor N
o / test item number, etc.) "and" attribute information for each type of object (creator, etc.) ", and objects are added at the timing of addition of a product or occurrence of a failure.

The cooperation between the objects is managed by a plurality of types of "relations" which are different for each meaning. Relations are "relationships that show the relationship between products (such as relations that link documents and programs created by looking at them)" and "relationships that show the relationship between product and change factor (which change factor Relations that indicate if the product has changed) ",
"Relationship showing the relationship between test items and change factors (failures) (relationship showing which failure occurred in which test)""Relationship showing the relationship between design review and change factors (points to be pointed out)" There are multiple types depending on the meaning of the relationship, such as "relation indicating which indication was made." Relations will be added when a failure occurs or when the repair is completed.

FIG. 1 is a block diagram showing a hardware environment for realizing a document and program management method in software development according to the present invention. In FIG. 1, 1 is a source server machine that centrally manages document files and program files, 2 is a database server machine that manages the objects shown in this invention, 3 is a document, each user terminal for program creation, and 4 is a test machine. Is.

FIG. 2 is a software configuration diagram for realizing the method proposed by the present invention. Each user terminal 3 provided with a GUI (Graphical User Interface) 30 has a change reason addition function 3A, a change reason-product cooperation function 3B, a test item addition function 3C, and a test item as necessary functions for implementation. Reason for change Cooperation function 3D,
Equipped with eight functions of test re-execution function 3E, product management function 3F, progress reflection function 3G, and diversion source-diversion destination cooperation function 3H, version management tool 1A of product management server machine 1, object management of database server machine 2 Database 2
Change reason object 2Aa in A, test item object 2Ab, product / work object 2Ac, relation management database 2B change reason-product object 2Ba, test item-change reason object 2B
b, diversion source-diversion destination relation 2Bc, test machine 4
Access the retest tool 4A.

FIG. 3 is a flow chart for explaining the contents of the change reason adding function 3A. Change reason addition function 3
As shown in FIG. 3, A adds the change reason object to the change reason object 2Aa in the object management database 2A based on the input of the change reason (steps S31, S332), and executes the relationship registration with the product. When performing, the reason for change in the relation management database 2B-the reason for change-product relation 2Ba is activated for the product relation 2Ba (steps S33, S3).
4). In step S33, if the relationship registration with the product is not performed, the process ends.

FIG. 4 is a flow chart for explaining the contents of the reason for change-product cooperation function 3B. The change reason-product cooperation function 3B is activated by the change reason adding function 3A, and as shown in FIG. 4, when the change reason has been designated, the object management database 2
The change reason object 2Aa in A is used to specify the change reason object and the product / work object 2
A related product object is designated from Ac (steps S41 to S43), a change reason-product cooperation relation is created, and stored in the change reason-product relation 2Ba in the relation management database 2B (step S44). If no change reason is designated in step S41, the process proceeds to step S43.

Further, FIG. 5 shows the above-mentioned test item addition function 3C.
3 is a flowchart illustrating the contents of the above. As shown in FIG. 5, the test item addition function 3C adds a test item object to the test item object 2Ab in the object management database 2A based on the input of the test item (steps S51 and S52).

FIG. 6 is a flow chart for explaining the contents of the test item-change reason cooperation function 3D. As shown in FIG. 6, the test item-change reason cooperation function 3D is as follows.
The test item object of the test item object 2Ab in the object management database 2A is specified, and the change reason object of the change reason object 2Aa is specified (steps S61 to S62) to create a test item-change reason relation and create a relation. Test Item in Management Database 2B-Relation Reason Relation 2
Store in Bb (step S63).

FIG. 7 is a flow chart for explaining the contents of the test re-execution function 3E. As shown in FIG. 7, the test re-execution function 3E is activated at the completion of the program change, and displays the reason for change (objects) associated with the changed program in the product relation 2Ba in the relation management database 2B. Do (step S71), object management database 2
After selecting the change reason objects (plurality) of the change reason object 2Aa in A (step S7).
2) Find the next change reason object (step S7)
3) If the treatment for all the reasons for change has not been completed (step S74), the relation management database 2
The test item associated with the change reason is extracted from the test item-change reason relation 2Bb in B (step 75), and the test is re-executed (re-test tool on the test machine) (step S76). After the test is re-executed, step S73
Then, the processing up to step S76 is repeated, and if the processing for all the reasons for change is completed in step S74, the processing ends.

FIG. 8 is a flow chart for explaining the contents of the product management function 3F. As shown in FIG. 8, the product management function 3F selects and specifies the product object of the product / work object 2Ac in the object management database 2A, and displays the current status of the product object (step S81). , S
82). If there is a change setting by the user, the status information of the product object is changed and stored in the product / work object 2Ac, and the progress reflection function is activated (steps S84, S85). In step S83 above,
If there is no change setting by the user, the process ends.

FIG. 9 is a flow chart for explaining the contents of the progress reflection function 3G. Progress reflection function 3G
Is started from the product management function 3F. As shown in FIG. 9, when the status change object has been specified, the status change object of the product / work object 2Ac in the object management database 2A is specified. (Steps S91, S92) If there is an object in the same level as the unstarted status, the status of the upper hierarchy object is set as unstarted and stored in the product / work object 2Ac, and the process proceeds to Step S98 described later (Step S93, S94). Step S9 above
If there is no object in the same layer in the unstarted status in step 3, the process proceeds to step S95, and if all the same layer objects are in the completed status, the status of the upper layer object is completed and stored in the product / work object 2Ac. (Step S96), Step S
Move to 98. If it is determined in step S95 that all the same hierarchy objects are not in the completion status, the status of the higher hierarchy object is set to "in preparation" and stored in the product / work object 2Ac (step S97). The process proceeds to the hierarchical object, and it is determined whether or not it is the highest layer. If it is the highest layer, the process ends (steps S98 to S100). In step S98, if there is no status change of the upper hierarchy object, the process ends. If the status change object has not been specified in step S91, the process proceeds to step S93.

Further, FIG. 10 is a flow chart for explaining the contents of the above-mentioned diversion source-diversion destination cooperation function 3H. As shown in FIG. 10, the diversion source-diversion destination cooperation function 3H selects and designates the diversion source object and the diversion destination object of the product / work object 2Ac of the object management database 2A, and creates the diversion source-diversion destination relation. And stores it in the diversion source-diversion destination relation 2Bc of the relation management database 2B (step S101).
~ S103).

FIG. 11 shows an example of a management system in which the products (documents and programs) created in software development and the work related thereto are hierarchically expressed.
TR according to the management system using the product management function 3F
It is managed by EE configuration. As shown in FIG. 11, the project has each work of designing, manufacturing, and testing, and the required specification is created by the work of summarizing the required specifications of the design, and the basic specification and the control processing basic are created by the work of creating the external specification. A specification and a GUI processing basic specification are created. Also, a basic DB specification and an individual DB specification are created by the production DB creation work, various function specifications are created by the function outline design work, and various programs are created by the production work.
Further, various processing unit test specifications are created by the unit test work of the test, and combination test specifications are created by the comprehensive test work.

Hereinafter, each embodiment of the present invention will be described in detail. Embodiment 1. FIG. 12 is a diagram illustrating a method of managing documents and programs in software development according to the first embodiment, and illustrates management of the reason for changing a document / program. As shown in FIG.
When a new change reason occurs, the change reason addition function 3A
(User activated) database server machine 2
The object is added to the object management database 2A. Further, if the document or program to be changed is clear at the time of registration, the reason for change-product cooperation function 3B is used to connect the document or program corresponding to the reason for change with a relation. In the system according to the first embodiment, each user gives an instruction from the GUI on the client, and the change reason addition function 3A existing on the client, the change reason-product cooperation function 3B,
Test item addition function 3C, test item-change reason cooperation function 3
D, test re-execution function 3E, product management function 3F, progress reflection function 3G, diversion source-diversion destination cooperation function 3H are activated, and the database on the database server (object management database, relation management database), production The product server and test machine are accessed for processing.

When the document or program corresponding to the change reason becomes clear later (at the time of executing the change processing, etc.), the document corresponding to the change reason and the document corresponding to the change reason are produced by using the change reason-product cooperation function 3B. Connect programs by relation. Similarly, the corresponding document or program is corrected (deletion of relation) using the reason for change-product cooperation function 3B.

When the modification of the document or program is completed, the dealt relation among the relations connected to the document or program is designated, and the attribute of the relation is set to "treated".

Thus, how the document or program is changed (or changed) with respect to the reason for change (including which version corresponds to which version) is managed. In the past, since the database showing the reason for the change and the (version) change of the document or program were disjointed, it was necessary to take time and effort such as double input by the user in order to manage the change contents and the reason. By adopting this method, it is possible to manage the correspondence between the change reason and the changed content with a simple operation.

Embodiment 2. FIG. 13 is a diagram for explaining a document and program management method in software development according to the second embodiment, and is for explaining test items, failures, and document / program management that affects them. As shown in FIG. 13, when the test content is fixed or when the test is performed, the test item addition function 3
Add an object indicating the test content to the database server machine (started by the user) using C. The test item addition function 3C is a function of adding a test item designated by the user to the object management database 2A that manages the test item.

If a failure occurs as a result of the execution of the test, an object indicating the failure is added to the object management database 2A of the database server machine 2 (started by the user) by using the change reason adding function 3A. Also,
Test item-reason of change Connect the failure contents corresponding to the test item by relation using the cooperation function 3D. The test item-change reason linking function 3D includes the test item object 2Ab managed by the object management database 2A.
And the reason for change object 2Aa managed in the object management database 2A (which test item caused which change reason occurred) and let the user specify that information as a relation in the relation management database 2B. It is a function to manage.

The reason for change and the corresponding change in the document or program are linked by the method described in the first embodiment.

As a result, the test content, the failure content for the test content, and the document or program modified correspondingly are managed in cooperation. Conventionally, test items, failure contents, and products were managed separately, so it was not possible to know what kind of test caused the failure, and after the repairer took time to reproduce the failure or repaired the program. It took time to consider what kind of confirmation test should be performed, but by adopting this method it is possible to manage the test items, fault details, and product correspondence with a simple operation. .

Embodiment 3. FIG. 14 is a diagram illustrating a method of managing documents and programs in software development according to the third embodiment, and illustrates a corresponding test item automatic re-execution method at the time of repairing a failure. Figure 1
As shown in FIG. 4, the automatic re-execution is enabled by using the re-test tool 4A during the test execution.

When a failure occurs during the execution of the test, by the method shown in the second embodiment, the test content, the failure content corresponding to the content, and the document or program changed corresponding to the content are managed in cooperation by the method shown in the second embodiment. To do.

When the program change is completed, the test re-execution function 3E is used to trace the relation between the objects (reason for change: failure → test item) to extract the test item causing the failure. On the other hand, the re-test tool 4A is activated to automatically re-execute the test for the test item that caused the change this time.

As a result, it is possible to confirm semi-automatically whether or not the test which caused the failure is properly operated when the failure is repaired. Previously, the result was OK in the rehabilitation test conducted by persons with disabilities
However, there were cases where the tester did not repair the test (due to differences in test procedures, etc.), but by using this method, reliable confirmation can be performed.

Fourth Embodiment FIG. 15 is a diagram illustrating a method of managing documents and programs in software development according to the fourth embodiment, and illustrates a progress status display method. As shown in FIG. 15, products (documents and programs) created in software development are managed in a TREE configuration according to the management system by using the product management function 3F (PDM tool or the like may be used). . In the management system TREE, the products created in the software development project and the work related thereto are hierarchically represented. FIG. 11 is an example of a management system.

When a document or program is newly created or deleted, it is added to the management system TREE by using the product management function 3F.

In the process of creating individual documents and programs, the product management function 3F is used to manage the status ("unstarted → under preparation → completed". Also, the same status is managed for each work.

When the status of an individual document or program is changed, the progress reflection function 3G is used to "confirm the status of all work / product in the same layer, and if even one is not started, the upper layer is not started. Then, the process of setting all to the completed state upper layer is completed, and otherwise setting the upper reorganization is being made ”. When the status of the upper layer is changed, the same process is repeated at the upper layer.

As a result, the progress record from the documents and programs created during software development to the work in the upper layer can be correctly grasped. In software development, it is necessary for each worker such as a project manager, system engineer, and programmer to grasp the progress at a necessary level according to their roles. In the past, progress reports were often self-reported, and there was a problem that lower and upper levels were not consistent, but by adopting this method, you can always know the correct progress status at the required level. .

Embodiment 5. FIG. 16 is a diagram for explaining a document and program management method in software development according to the fifth embodiment, and illustrates a diversion management method in the case of developing similar software in parallel in a plurality of projects. . As shown in FIG. 16, when performing parallel development of the software of the project that is being developed in advance, using the diversion source-diversion destination cooperation function 3H, the version of the software that has been diverted is connected and managed by the relation. Keep it.

Changes in products (documents and programs) in each project are managed by a version management tool or the like.

If necessary during development, refer to the relations connected by the diversion source-diversion destination cooperation function 3H and the change history in the version management tool to check the changes after versioning when diversion to another project. , If necessary, reflect the changes in another project.

As a result, the changes due to the obstacles in the similar project can be efficiently reflected in other projects. In the past, since the contents of changes in other projects after diversion could not be grasped, there were cases where the same failure was detected in both projects and repaired in duplicate, but information to prevent waste by adopting this method was used. It can be presented.

[0045]

As described above, according to the present invention, products (documents, programs, etc.) created in software development, change factors (points pointed out in the design review, failure information at the time of testing, etc.), tests It is possible to manage the information (test item, test result, etc.) related to the object as an object and manage the relationship between each object.

[Brief description of drawings]

FIG. 1 is a hardware configuration diagram for realizing Embodiments 1 to 5 of the present invention.

FIG. 2 is a software configuration diagram for realizing Embodiments 1 to 5 of the present invention.

FIG. 3 is a flowchart of a change reason adding function for realizing the first and second embodiments of the present invention.

FIG. 4 is a flowchart of a change reason-product cooperation function for realizing the first and second embodiments of the present invention.

FIG. 5 is a flow chart of a test item addition function for realizing Embodiment 2 of the present invention.

FIG. 6 is a flowchart of a test item-change reason linking function for implementing Embodiment 2 of the present invention.

FIG. 7 is a flowchart of a test re-execution function for implementing Embodiment 3 of the present invention.

FIG. 8 is a flowchart of a product management function for realizing Embodiment 4 of the present invention.

FIG. 9 is a flowchart of a progress reflection function for realizing Embodiment 4 of the present invention.

FIG. 10 is a flow chart of a diversion source-diversion destination cooperation function for realizing Embodiment 5 of the present invention.

FIG. 11 is an explanatory diagram of a management system of the present invention.

FIG. 12 is a flowchart for managing the reason for changing a document program according to the first embodiment of the present invention.

FIG. 13 is a flow chart for managing test items and faults and the affected document / program according to the second embodiment of the present invention.

FIG. 14 is an explanatory diagram of corresponding test item automatic re-execution processing at the time of failure repair according to the third embodiment of the present invention.

FIG. 15 is an explanatory diagram of a progress status display process according to the fourth embodiment of the present invention.

FIG. 16 is an explanatory diagram of diversion management processing according to the fifth embodiment of the present invention.

[Explanation of symbols]

1 product management server machine, 1A version management tool, 2
Database server machine, 2A object management database, 2Aa change reason object, 2Ab
Test item object, 2Ac Product / work object, 2B relation management database, 2Ba
Reason for change-Product relation, 2Bb Test item-Reason for change Relation, 2Bc Diversion source-Diversion destination, 3 User terminal, 3A Change reason addition function, 3B
Reason for change-product cooperation function, 3C test item addition function, 3D test item-change reason cooperation function, 3E test re-execution function, 3F product management function, 3G progress reflection function, 3H diversion source-diversion destination cooperation function, 4 Test machine,
4A Retest tool.

Claims (5)

[Claims] 1. The management of the design document indicating the design content created in software development, the test document indicating the test content, and the individual document and the modification content of the program and the reason for the modification in cooperation with the program. A method for managing documents and programs in software development. 2. In the software development testing stage, the relationship between the test content and the failure, the design document indicating the failure and the design content of the product resulting from the failure, the test document indicating the test content, and the program change content are linked. A method for managing documents and programs in software development, which is characterized by performing management by means of. 3. In the software development test stage, the test implementation status and its results, and the program changes resulting therefrom are managed, and the retested faults are automatically retested to confirm the results. A method for managing documents and programs in software development. 4. A design document showing design contents created in software development, a test document showing test contents, and a production status of a program are grasped,
A method of managing documents and programs in software development, characterized by grasping the progress status of the entire development project. 5. A design document showing design contents created in parallel development of a plurality of similar software,
A method for managing documents and programs in software development, characterized by managing test documents showing test contents and individual documents and diversion history / change reflection history of the programs.