JP2010039751A - Software development system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent that influence of correction extends to a wide range when correcting a part of software, and to minutely extract a range wherein the correction influences another part. <P>SOLUTION: A self key and an upper key are imparted to a document or the like, the document or the like inside its own process is stored based on the self key, and the document or the like of an upper process wherein the correction influences the document or the like inside the own process is stored based on the upper key. A process definition file for storing the document or the like inside each process by the processes is created, and relation between the document or the like inside each process and the document or the like inside a process positioned below the process is defined by the process definition file. When the document or the like inside one process is corrected, the document or the like inside the upper process is retrieved based on the upper key of the document or the like, the document or the like inside the lower process is retrieved based on the process definition file, and the range to which the influence of the correction extends is extracted. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a software development system.

  Systems that support software development are known. For example, a requirement description document that describes software requirements, a design model created from the requirement description document, and a development support device that supports the development of deliverables that are program codes created from the design model have been proposed Yes. The development support apparatus includes a storage unit that stores a product and correspondence information between the product, a correction reception unit that receives an input of the product to be corrected, and the product received by the correction reception unit as a starting point. By tracking correspondence information between deliverables stored in the department, a revision tracking section that tracks other artifacts affected by the artifact to be modified, and a correction notification that notifies the artifacts tracked by the revision tracking section (See, for example, Patent Document 1).

  In addition, a software development support apparatus that supports design document creation in software development has been proposed. In this development support apparatus, the design document belongs to one of the development phases and has at least one design element constituting the design document. The design element is an implementation element that realizes each element and a dependent element that depends on each element. And storage means in which design element information including information on the realization element and the dependency element is recorded, and information on the realization element and the dependency element recorded in the storage means at the time of design change Retrieval means for extracting a realization element that realizes a change request when it occurs, a dependent element to which the change spreads, and a design element that needs to be changed based on the realization element and the dependence element searched by the search means And a visualization device that acquires and displays the information (for example, see Patent Document 2).

  Also, a design information management system has been proposed that registers upstream design information, downstream design information, and related information between them when creating software products while stepping down design information from upstream to downstream. ing. The design information management system includes a product storage unit that stores software products, a design information storage unit that stores design information and related information between the design information, and software product based on the software product description rules. Design information identification ID and design information, and a function of extracting design information identification ID representing the relationship between upstream software products, storing design information in software products in units of design information identification ID, and software It is characterized by having design information analysis means for storing the association between design information identification IDs in the deliverable (see, for example, Patent Document 3).

JP 2007-122135 A JP 2007-18334 A JP 2007-199755 A

  However, when the requirement description document is modified, the development support apparatus disclosed in Patent Document 1 tracks a linked design model from the requirement description document, tracks a linked program code from the design model, Furthermore, the linked design model is traced recursively from the program code, and the linked requirement description document is traced from the design model. The same applies when the program code is modified first or the design model is modified first. Since the tracking is performed recursively in this way, there is a problem that the influence of the first correction may spread over a wide range.

  Since the software development support apparatus disclosed in Patent Document 2 is managed in units of design documents belonging to the development phase, even if a part of a design document belonging to a certain development phase is corrected, All the design documents will be affected by the modification. That is, there is a problem in that a range in which a part of the design document affects others cannot be extracted in detail for each part to be corrected, not in the unit of the design document.

  The design information management system disclosed in Patent Document 3 does not consider the case where a plurality of downstream design information is related to one upstream design information. Therefore, when the upstream design information is corrected, the correction is performed. There is a problem that there is a possibility that the influence of the above may extend over a wide range. In addition, since ID is used as related information, the relationship between upstream design information and downstream design information is fixed, and it is difficult to change the upstream relationship on the downstream side. .

  An object of the present invention is to provide a software development system capable of preventing the influence of the modification from extending over a wide range when a part of the software is modified in order to solve the above-described problems caused by the prior art. To do. It is another object of the present invention to provide a software development system capable of finely extracting a range in which the modification affects others when a part of the software is modified.

  This software development system assigns a first keyword and a second keyword to a document or source code in each process when developing software through a plurality of hierarchized processes, and based on the first keyword The document or source code in the own process is stored, and the document or source code of the upper process that is affected by the modification to the document or source code in the own process based on the second keyword is stored. The software development system stores a document or source code in each process for each process, and defines a relationship between the document or source code in each process and the document or source code in a sub-process of the process. Is provided.

  Further, when the document or source code in any process is modified, the software development system converts the document or source code in the upper process based on the second keyword assigned to the document or source code. Search means for searching is provided. When a document or source code in any process is modified, the search means searches for a document or source code in a sub-process of the document or source code based on the process definition means.

  This software development system assigns a process identifier to a document or source code in each small process and stores the document or source code in each small process based on the process identifier when each process further includes a plurality of small processes. To do. Then, when the document or source code in any process is modified, the retrieval means retrieves the document or source code of each small process in the own process affected by the modification based on the process identifier. .

  According to this software development system, when a document or source code in any process is modified, the document or source code affected by the modification is searched from the upper process, own process, and lower process. The When the upper process, the own process, or the lower process further includes a plurality of small processes, a document or source code affected by the correction is searched in units of small processes.

  According to this software development system, when a part of software is corrected, the effect of the correction can be prevented from reaching a wide range. In addition, when a part of the software is corrected, there is an effect that a range in which the correction affects others can be extracted in detail.

  Exemplary embodiments of the software development system will be described below in detail with reference to the accompanying drawings.

(Hardware configuration of software development system)
FIG. 1 is an explanatory diagram of a hardware configuration of the software development system according to the embodiment. As shown in FIG. 1, the software development system 1 includes a CPU 101, a ROM 102, a RAM 103, an HDD (hard disk drive) 104, an HD (hard disk) 105, an FDD (flexible disk drive) 106, and a removable recording. As an example of the medium, an FD (flexible disk) 107, a display 108, an I / F (interface) 109, a keyboard 110, a mouse 111, a scanner 112, and a printer 113 are provided. Each component is connected by a bus 100.

  Here, the CPU 101 controls the entire software development system 1. The ROM 102 stores a program such as a boot program. The RAM 103 is used as a work area for the CPU 101. The HDD 104 controls reading / writing of data with respect to the HD 105 according to the control of the CPU 101. The HD 105 stores data written under the control of the HDD 104. The FDD 106 controls reading / writing of data with respect to the FD 107 according to the control of the CPU 101. The FD 107 stores data written under the control of the FDD 106.

  In addition to the FD 107, the removable recording medium may be a CD-ROM (CD-R, CD-RW), MO, DVD (Digital Versatile Disk), memory card, or the like. The display 108 displays data such as a document, an image, and function information as well as a cursor, an icon, or a tool box. As this display 108, for example, a CRT, a TFT liquid crystal display, a plasma display, or the like can be adopted.

  The I / F 109 is connected to a network 114 such as the Internet or a local area network through a communication line, and is connected to other devices via the network 114. The I / F 109 controls an internal interface with the network 114 and controls data input / output from an external device. For example, a modem or a LAN adapter can be employed as the I / F 109.

  The keyboard 110 includes keys for inputting characters, numbers, various instructions, and the like, and inputs data. Moreover, a touch panel type input pad or a numeric keypad may be used. The mouse 111 performs cursor movement, range selection, window movement, size change, and the like. A trackball or a joystick may be used as long as they have the same function as a pointing device. The scanner 112 optically reads an image and takes in the image data into the software development system 1. The scanner 112 may have an OCR function. The printer 113 prints image data and document data. As the printer 113, for example, a laser printer or an ink jet printer can be employed.

(Functional configuration of software development system)
FIG. 2 is a block diagram showing a functional configuration of the software development system. As shown in FIG. 2, the software development system 1 includes a document dependency processing unit 2, a document storage unit 3, a main processing unit 4, and an object generation unit 5. The document dependency processing unit 2 includes a process definition file 6, a process definition storage unit 7, a correction processing flag storage unit 8, and a document version number check unit 9.

  The document storage unit 3 stores a document or source code (hereinafter referred to as a document or the like). A document etc. consists of a header part and a document body. The document body is the body of the document or the source part of the source code. The header portion includes a self key (Self Key) as a first keyword for identifying the self-document, etc., and a second keyword for identifying a document or the like positioned higher than the self-document (hereinafter referred to as a high-order document or the like). As an upper key, a process identifier for identifying a process in which the own document or the like is generated, and first, second and third flags indicating various states of the own document or the like. .

  The self key may be any keyword such as a mechanical name as long as it can distinguish the own document from other documents, etc., but is preferably a keyword of meaning or content representing the content of the document or the like. Is good. There can be any number of self-keys in one document, etc., except in the same process, unless the number of upper documents etc. and the number of documents immediately below are in a 1: N relationship, Must be unique.

  The self key is also written on the document body. The first edition number is assigned to the self key described in the document body. This first version number is updated by the user. A second edition number is assigned to the self key of the header portion. The second version number is updated by the system side, for example, the document storage unit 3. The first version number and the second version number are, for example, integers starting from 0, incremented by 1, and then return to 0 after 9.

  The upper key is a self-key of the upper document registered in the upper document. By registering a self-key of a higher-level document or the like as an upper key in the own document or the like, the higher-level document or the like to which the own document or the like is connected can be specified.

  The first flag is turned on when spontaneous correction is performed on the own document or the like. The first flag is turned off when the correction of all documents that need to be corrected is completed, starting with the correction of the document itself. Hereinafter, a document that is first corrected spontaneously in this series of correction processes is referred to as a base document. The second flag is turned on when it is necessary to modify or check the own document or the like due to the influence of modification of another document or the like. The third flag is turned on when correction of the own document or the like is completed.

  The process definition file 6 stores a document or the like for each process, and also stores a dependency relationship between the self-document and the like, and a document or the like (hereinafter referred to as a sub-document or the like) positioned below the self-document. The process definition storage unit 7 stores a process definition file 6.

  The correction processing flag storage unit 8 searches for a higher order document or the like based on the upper key, and searches for a lower order document or the like based on the process definition file 6. Further, the correction processing flag storage unit 8 searches for a document or the like in which the same self key is set in the process at the same level based on the process definition file 6. The correction processing flag storage unit 8 stores the states of the first, second, and third flags of the corresponding document and the like based on the search results.

  The document version number check unit 9 compares the self-key version number (first version number) in the document body with the self-key version number (second version number) in the header part. If there is a difference in the version numbers as a result of the comparison, the document version number check unit 9 determines that the document body has been changed. If the version numbers are the same, the document version number check unit 9 determines that the version number of the self key described in the document body has not been changed.

  When the document version number check unit 9 determines that the version number of the self key in the document body has not been changed, the main processing unit 4 displays a message prompting the user to update the version number on the display 108. . The main processing unit 4 displays a document or the like in which the first flag or the second flag is turned on on the display 108 and prompts the user to correct the document or the like.

  The object generation unit 5 includes a compiler. The object generation unit 5 checks the first, second, and third flags of each document or the like via the correction processing flag storage unit 8. As a result, when the first flag and the second flag are off, the object generation unit 5 permits the generation of the object and generates the object. When the first flag or the second flag is on, the object generation unit 5 does not permit the generation of the object.

(Explanation of specific examples)
FIG. 3 is an explanatory diagram showing an example of the concept of process definition. For example, as shown in FIG. 3, the software development process includes a BI process for generating a functional specification, a BD process for generating a basic design document, an FD process for generating a functional design document, and an MK process for generating a source (comment). Suppose that For example, in the BI process, an “A1 entire screen” document or the like related to the entire screen is generated. In the BD process, it is assumed that a “B1 entire layout” document or the like is generated as a subordinate document or the like such as an “A1 entire screen” document. Further, the BD process is composed of a plurality of small processes, and “B11 name”, “B12 departure”, “B13 arrival”, “B14 route display”, and “B21 execution” are performed in each small process as a “B1 overall layout” document or the like. Are generated.

  In the FD process, a “C1 position” document or the like is generated as a subordinate document or the like such as an “B1 overall layout” document. In addition, a “C2 font” document or the like is generated as a subordinate document or the like of each of the “B11 name”, “B12 departure”, “B13 arrival”, and “B14 route display” documents. It is assumed that a “C3 display” document or the like is generated as the document or the like. In the MK process, as documents such as “C1 position”, “C2 font”, and “C3 display” documents, etc., “D1 position”, “D2 font”, “D3 display” documents, etc., respectively. Is generated. In the conceptual diagram of the process definition shown in FIG. 3, one horizontal row corresponds to one constituent unit.

  4, 5, 6, and 7 are explanatory diagrams illustrating an example of a configuration of each document such as “A1 overall screen”, “B1 overall layout”, “B11 name”, and “C1 position”, respectively. . As shown in FIG. 4, “overall screen (*)” is set as a self key in the header portion of the “A1 entire screen” document 11 or the like. After the self key, a number * (* = 0, 1,..., 9) representing the second edition number is enclosed in parentheses. The “A1 whole screen” document 11 or the like 11 is a document or the like corresponding to the highest level in the process definition, so no upper key is set. A process group code “A1”, which will be described later, is set as the process identifier. In the document body, a self-key of “whole screen (*)” is described with a first version number.

  As shown in FIG. 5, in the “B1 overall layout” document 12 or the like, “overall layout (*)”, “overall screen” with a second version number as a self key, an upper key, and a process identifier in the header part, respectively. ”And the process group code“ B1 ”are set. In the document body, the “whole layout (*)” with the first version number is described.

  As shown in FIG. 6, in the “B11 name” document etc. 13, “name (*), input (), kanji ()”, “overall layout, “Input, kanji” and a sub-process identifier “B: B11” to be described later are set. In the example shown in FIG. 3, the “B11 name” document etc. 13 has “input” and “kanji” self-keys in addition to “name”, and these self-keys are listed in the header portion. However, a number * representing the second version number is enclosed in parentheses to the “name” self key, but the self key in the same process is out of contrast with the version number, so “input” and “ “Kanji” self-keys are given only parentheses without numbers representing the second edition number. “Name (*)” with the first version number is written in the document body.

  As shown in FIG. 7, in the “C1 position” document or the like 14, “position (*)”, “overall layout” and “second layout number” are used as a self key, an upper key, and a process identifier in the header part, respectively. A process group code “C1” is set. In the document body, “position (*)” with the first version number is described. Since the configuration of other documents is the same, it is omitted.

  FIG. 8 is an explanatory diagram showing an example of the database structure of the process definition file. As shown in FIG. 8, the process definition file 6 includes a reference database 21 and an extended database 22. Records of the reference database 21 include, for example, “forward pointer”, “process identifier”, “sub-process identifier”, “key name”, “process group code”, “side pointer”, “next pointer”, and “key pointer”. It has each field. The record of the extended database 22 has, for example, “forward key pointer”, “key name”, and “next key pointer” fields.

  The “forward pointer” field stores a pointer indicating a link to the previous process between processes. The “process identifier” field stores data indicating process classification such as BI and BD. The “sub-process identifier” field stores data indicating the detailed process classification in the same self key. The detailed process classification is B11 or B12. The “key name” field stores data indicating the name of the self key. In the “process group code” field, a code indicating a key in the same process is stored. In the “side pointer” field, a pointer indicating a link in the same process or a link in the same self key is stored. The “next pointer” field stores a pointer indicating a link to a subsequent (next) process between processes. In the “key pointer” field, a pointer to a key name in the same self key is stored. The “forward key pointer” field stores a pointer indicating the link source to the key name in the same self key. The “next key pointer” field stores a pointer indicating the next link to the key name in the same self key.

  FIG. 9 is an explanatory diagram showing an example of a process definition file. In this example, the database structure shown in FIG. 8 is applied to the process definition shown in FIG. As shown in FIG. 9, in the record 31 with the first pointer “0”, “entire screen” which is a self key in the BI process is registered as a key name. In the record 32 of the next pointer “100”, “overall layout” which is a self key in the BD process is registered as a key name. In the record 31 with the pointer “0”, “100” is registered as the next pointer. In the record 32 with the pointer “100”, “0” is registered as the forward pointer.

  Since there is an in-process self key in the BD process, the “name”, “departure”, “arrival”, “route display”, and “execute” in-process self keys are respectively designated as key names “101”, “102”, “103”, “104” and “105” are registered in the records 33, 34, 35, 36 and 37. Since these are records in the same self-key of the BD process, a sub process identifier, a process group code, and a side pointer are registered in each, and are set as horizontal links. Since the records in the same self key of these BD processes are at the same level, “100” is registered as the forward pointer and “200” is registered as the next pointer. Furthermore, since these records have a self key in the same self key, key pointers “10000” to “10008” are registered as extended information for each record. Records 41, 42, 43, 44, 45, 46, 47, 48, 49 with pointers “10000” to “10008” are records of the extended database.

  In the record 38 of the pointer “200”, “position” which is a self key in the FD process is registered as a key name. In the record 38 of the pointer “200”, “100” is registered as the forward pointer, and “300” that is a link to the source is registered as the next pointer. Regarding the FD process, “font, number of digits” is registered as the key name in the record 39 of the pointer “210”, and “display” is registered as the key name in the record 40 of the pointer “220”. In the record 39 of the pointer “210”, “100” is registered as the forward pointer, and “310” that is a link to the source is registered as the next pointer. In the record 40 with the pointer “220”, “100” is registered as the forward pointer, and “320” that is a link to the source is registered as the next pointer.

  Since the FD process is not the same self-key link as the BD process, the sub process identifier is not registered in each record of the FD process. Further, the process group code is different in each record of the FD process. The records after the pointer “300” are not shown. FIG. 10 conceptually shows the links defined by the process definition file shown in FIG. In FIG. 10, numbers such as “0” and “100” are pointers of the records shown in FIG. Arrows indicate dependencies.

  FIG. 11 is an explanatory diagram illustrating an example of a function matrix in which dependency relationships of documents and the like are summarized. In the above-described example, in the BD process, the number of upper documents and the number of documents immediately below are in a 1: N relationship. In such a relationship, a function matrix 51 shown in FIG. 11 may be prepared, and a lower document or the like that turns on the second flag may be determined based on the function matrix 51. In the function matrix 51 shown in FIG. 11, “1” indicates that a document or the like includes a related item (such as “input”) at the left end of the matrix, and “0” does not. When the “input” related item such as the “B11 name” document is corrected, it is necessary to correct each of the “B12 departure” and “B13 arrival” documents. Is turned on. On the other hand, since the “B14 route display” and “B21 execution” documents do not include the “input” related items, it is not necessary to modify these documents.

  The function matrix 51 described above is generated by the process definition storage unit 7 based on the process definition file 6, for example. For example, in the case of the configuration shown in FIG. 9, the process definition storage unit 7 lists process group codes from the reference database 21 and searches for codes registered in a plurality of records. In the example shown in FIG. 9, “B1” corresponds. Next, the process definition storage unit 7 extracts a record in which the sub process identifier is registered from a plurality of records in which “B1” is registered as the process group code. In the example illustrated in FIG. 9, the records in which “B11” to “B12” are registered correspond. Next, the process definition storage unit 7 refers to the extended database 22 based on the key pointer of each record in which the sub-process identifiers “B11” to “B12” are registered, and the key names registered in the extended database 22 Take out. If the extracted key name is not in the function matrix 51, the process definition storage unit 7 adds the name to the left end of the matrix. If the name is already in the function matrix 51, the process definition storage unit 7 "1" is stored in the column of. By repeating this, the function matrix 51 is completed.

  FIG. 12 is an explanatory diagram illustrating an example of a screen displayed by the main processing unit. As shown in FIG. 12, on the screen of the display 108, a process selection unit 61 that prompts the user to select a process, a document related display unit 62 that displays related information (link information) such as a document, and flags of related documents and the like. The related document flag display unit 63 for displaying the information of the document, the document information display unit 64 for displaying the information of the header of the own document, and the document processing unit 65 for displaying the document body of the own document or the like are displayed.

  In the functional configuration described above, the document storage unit 3 has functions as a first storage unit and a second storage unit. The process definition file 6 and the process definition storage unit 7 have a function as process definition means. The correction process flag storage unit 8 has functions as a search unit and a storage unit. The main processing unit 4 has a function as processing means. Further, in the hardware configuration shown in FIG. 1, the document storage unit 3 is configured by a secondary storage device such as the HD 105. The process definition file 6 is stored in a secondary storage device such as the HD 105. The main processing unit 4, the object generation unit 5, the process definition storage unit 7, the correction processing flag storage unit 8, and the document version number check unit 9 execute a program related to each function stored in the storage unit such as the ROM 102 or the HD 105 on the CPU 101. This is realized. Alternatively, various documents and the like, the process definition file 6 and the function matrix 51 may be stored in a storage device on the network 114 and downloaded from the network 114 via the I / F 109 for use. A program that realizes the functions of the main processing unit 4, the object generation unit 5, the process definition storage unit 7, the correction processing flag storage unit 8, and the document version number check unit 9 is also downloaded from the network 114 via the I / F 109. And may be used.

(Document processing procedure in software development system)
FIG. 13 to FIG. 15 are flowcharts showing document creation or correction processing procedures in the software development system. As shown in FIG. 13, first, when the document creation process is started, it is determined whether or not a document or the like is newly created (step S1). Since it is newly created (step S1: Yes), the user creates the process definition file 6 and sets a self key indicating the document content of the BI process (step S2). It is determined whether or not the creation is finished (step S3). If finished (step S3: Yes), the process is finished.

  If the creation is not finished (step S3: No), the user writes a self key with a version number in each document body and creates a header portion (step S4). The user registers a self key with a version number in the header part, registers a process group code as a process identifier, and first, second, and third flags (in the flowchart, flag 1, flag 2, and flag 3 respectively. Is set). When creating a document or the like for the BI process, the user does not need to register an upper key in the header portion because it is the highest-level document or the like. Next, the user registers a self key in the process definition file 6 (step S5) and ends the process.

  When adding a document or the like, since it is not a new creation of a document or the like (step S1: No), it is determined whether or not a document or the like is added (step S6). Since it is addition (step S6: Yes), a user performs the process of step S2-step S5 about the document etc. to add. However, since the process definition file 6 has already been created in the document addition process, it is not necessary to create a new process definition file 6 in step S2. In addition, since a document for the BD process, the FD process, or the MK process is created in the document addition process, the user registers the upper key in the header part in step S4, and the process group code or sub-process identifier is used as the process identifier. Register. Further, the user needs to appropriately modify the data stored in each field of the process definition file 6 according to the added document or the like.

  The user repeats the addition process of step S1, step S6, and step S2 to step S5, thereby adding a document for the BD process, the FD process, or the MK process. When creating or adding a document or the like, it is preferable to create a document or the like in units of self-keys grouped in the process definition file 6.

  When correcting a document or the like, since the document or the like is not added (step S6: No), the user opens the document or the like to be corrected as the base document (step S7). Next, the process definition storage unit 7 turns on a correction required flag and a base point flag such as a base point document in the process definition file 6 (step S8). In addition, in the database structure and specific example of the process definition file 6 shown in FIGS. 8 and 9, each field of a correction required flag and a base point flag is omitted.

  Next, the user modifies the document body such as the opened base document, and after the modification is completed, the version number of the self-key described in the document body is updated, and the base document or the like is saved (step S9). Using the saving as a trigger, the document version number check unit 9 determines whether or not the self-key version number in the document body and the self-key version number in the header part are different for the saved base document or the like (step S10). ). As a result, if the version numbers are different (step S10: Yes), the correction processing flag storage unit 8 determines that the base document or the like has been corrected, and turns on the first flag and the third flag such as the base document. To. Further, the process definition storage unit 7 turns off a correction required flag such as a base document of the process definition file 6 (step S11).

  Next, the correction processing flag storage unit 8 searches the related upper document etc. based on the upper key of the header part of the corrected base document etc., and turns on the second flag of the header part of the corresponding upper document etc. To. In addition, the process definition storage unit 7 turns on a correction required flag for the corresponding upper document in the process definition file 6 (step S12). It is determined whether or not flag operations for all corresponding upper documents have been completed (step S13). If they have not been completed (step S13: No), search and flag operations for upper documents and the like are performed until the completion. repeat.

  When the flag processing for the upper document or the like is completed (step S13: Yes), as shown in FIG. 14, the correction processing flag storage unit 8 refers to the process definition file 6 and is a document in the same level as the base document. Etc. (hereinafter referred to as peer documents, etc.) are searched for documents having the same self key registered, and the second flag in the header portion of the corresponding peer document etc. is turned on. In addition, the process definition storage unit 7 turns on a correction required flag such as a corresponding peer document in the process definition file 6.

  When the flag processing for the peer document or the like is completed, the correction processing flag storage unit 8 refers to the process definition file 6 to search for a lower document related to the base document or the like, and in the header portion of the corresponding lower document or the like. Turn on the second flag. In addition, the process definition storage unit 7 turns on a correction required flag for a corresponding lower document in the process definition file 6 (step S14). It is determined whether or not flag operations for all corresponding lower documents have been completed (step S15). If not completed (step S15: No), search for lower documents and flag operations are performed until the operation is completed. repeat.

  When the flag processing for the subordinate document or the like is completed (step S15: Yes), the main processing unit 4 displays the document or the like for which the second flag is turned on on the display 108, and prompts the user to make corrections. The user sequentially modifies the upper document or the like in which the second flag is turned on, updates the self-key version number described in each document body, and saves it. The correction processing flag storage unit 8 turns off the second flag such as the saved upper document and turns on the third flag. In addition, the process definition storage unit 7 turns off a correction required flag for a corrected upper document or the like in the process definition file 6 (step S16). It is determined whether or not the correction of the upper document to be corrected has been completed (step S17). If not completed (step S17: No), the correction process for the upper document or the like is repeated until the process is completed.

  When the correction process for the upper document is completed (step S17: Yes), the user similarly corrects the peer document and the lower document, updates the self-key version of the document body, and saves it. Accordingly, the correction processing flag storage unit 8 turns off the second flag such as the stored peer document and the lower document, and turns on the third flag. In addition, the process definition storage unit 7 turns off the correction required flag for the corrected peer document and the lower document in the process definition file 6 (step S18). It is determined whether or not the modification of the peer document etc. and the subordinate document to be corrected has been completed (step S19). If not finished (step S19: No), the peer document etc. and the subordinate document until the completion. Repeat the correction process.

  When the correction process for the peer document and the lower document is completed (step S19: Yes), the correction process flag storage unit 8 turns off the first flag such as the base document. Further, the process definition storage unit 7 turns off the base point flag such as the base point document in the process definition file 6 (step S20), and ends the document correction process. The process for the peer document or the like is executed, for example, when the correction process is performed using the “B11 name” document or the like as the base document.

  On the other hand, when the revision of the base document is completed and the version number of the self key in the document body is compared with the version number of the self key in the header part, the version number is the same (step S10: No). As shown in FIG. 15, the main processing unit 4 displays on the display 108 that the version number of the self key in the document body has not been changed, and prompts the user to update the version number (step S21). When the user does not update the version number of the self key in the document body (step S22: Yes), it is determined that the correction contents of the own document etc. are completed in the own document etc. and do not affect other documents etc. Then, the process definition storage unit 7 turns off the correction required flag and the base point flag such as the base document of the process definition file 6 (step S23), and ends the correction process of the document and the like. As a result of prompting the user to update the version number, when the user updates the version number of the self key in the document body (step S22: No), the process returns to step S9, and after updating the version number of the self key, The above-described related document correction process is performed.

  FIG. 16 is a flowchart showing an object generation processing procedure in the software development system. As shown in FIG. 16, when the object generation process is started, the object generation unit 5 checks the flag of the header part in various documents etc. via the correction processing flag storage unit 8. If all the first, second, and third flags are off or only the third flag is on (Yes in step S31), the object generation unit 5 Allows the creation of objects. As a result, the object generation unit 5 performs compilation and linkage processing (step S32), and ends the object generation processing. As a result of checking the flag, if any of the documents to be compiled has the first flag or the second flag turned on (step S31: No), the object generation unit 5 permits the generation of the object. do not do. In this case, the process returns to step S1.

  As described above, according to the present embodiment, it is possible to search for a document or the like having the same self key set in the same level process, so that a document or the like affected by the correction can be extracted in detail. . In addition, by using a function matrix when the number of upper documents and the number of documents immediately below are in a 1: N relationship, it is possible to prevent the influence of corrections on one document from reaching a wide range. Can do. In addition, when a modification that does not affect other documents or the like is performed, other documents or the like are not searched, and unnecessary document search processing is not required. In addition, since the dependency with the upper document is specified by the upper key and the dependency is specified by the process definition file for the lower document, etc., even if the lower document or the phase to be created is undecided at the initial stage of design Documents that have been created can be stored immediately.

  In addition, when any of the documents is modified, the documents affected by the modification are retrieved from the upper documents, peer documents, and lower documents, and the contents of modification to the base document are reflected. be able to. Therefore, it is possible to prevent inconsistency between a plurality of documents having dependencies. In addition, the uniqueness of the contents from the design document to the source code in software development can be guaranteed without adding any special work.

  As described above, the present invention is not limited to the above-described embodiment, and various modifications can be made. For example, a document or the like is a design document generated in each process, but each document or the like may be an entire process design document or may be created and stored as a unit for each function. At that time, a keyword may be inserted into each document or the like, and this keyword may be used as a self-key to represent the document or the like. Further, the self-key version number is not limited to 0 to 9, but may be extended to a numerical value of 10 or more and used as the version number representing the original revision history.

  The following additional notes are disclosed with respect to the embodiment described above.

(Supplementary Note 1) A software development system for developing software through a plurality of hierarchical processes, and a document or source in its own process based on a first keyword assigned to the document or source code in each process Document or source of a higher-level process in which the first storage means for storing the code and the correction of the document or source code in its own process are affected based on the second keyword assigned to the document or source code in each process Second storage means for storing code; process definition means for defining a relationship between a document or source code in each process and a document or source code in a sub-process of the process; and a document or source in any process Documents or software affected by the modification to the code Search means for searching for a document or source code in the upper process based on the second keyword and searching for a document or source code in the lower process based on the process definition means; A software development system characterized by comprising.

(Supplementary note 2) A first version number which is given to a document or source code in each process and updated whenever the document or source code is modified, and is given to the first keyword, and the document or source A second version number that is updated when modification of all documents or source code affected by the modification to the code is completed, and the search means includes the first version number and the second version number. The software development system according to appendix 1, wherein the search processing is performed with a difference between the two as a trigger.

(Supplementary Note 3) Each process further includes a plurality of small processes, and further includes a process identifier that is given to a document or source code in each small process and identifies the small process, and the first storage unit includes the process Based on the identifier, the document or source code in each sub-process in the process is stored, and the search means stores the document or source code affected by the modification to the document or source code in any process. The software development system according to appendix 1 or 2, wherein a document or source code of each small process in the process is searched based on the process identifier.

(Supplementary note 4) The software development system according to any one of supplementary notes 1 to 3, wherein the first keyword is the second keyword assigned to a document or source code of a higher-level process.

(Supplementary Note 5) A first flag that is given to a document or source code in each process and indicates that the correction is performed independently from other documents or source code, and a document or source code in each process. A second flag that is given and indicates that the correction is made depending on other documents or source code; a third flag that is given to the document or source code in each step and indicates that the correction is completed; The software according to any one of appendices 1 to 4, further comprising storage means for storing the state of each flag when a document or source code in any step is modified Development system.

(Supplementary note 6) The software development system according to supplementary note 5, further comprising processing means for prompting modification of a document or source code in which the first flag or the second flag is turned on.

It is explanatory drawing which shows the hardware constitutions of the software development system concerning embodiment. It is a block diagram which shows the functional structure of the software development system concerning embodiment. It is explanatory drawing which shows an example of the concept of process definition. It is explanatory drawing which shows an example of structures, such as a document. It is explanatory drawing which shows an example of structures, such as a document. It is explanatory drawing which shows an example of structures, such as a document. It is explanatory drawing which shows an example of structures, such as a document. It is explanatory drawing which shows an example of the database structure of a process definition file. It is explanatory drawing which shows an example of a process definition file. It is explanatory drawing which shows notionally the link defined by the process definition file shown in FIG. It is explanatory drawing which shows an example of the function matrix which put together the dependence relationships, such as a document. It is explanatory drawing which shows an example of a display screen. It is a flowchart which shows the creation or correction processing procedure of the document in the software development system concerning Embodiment. It is a flowchart which shows the continuation of FIG. It is a flowchart which shows the continuation of FIG. It is a flowchart which shows the object production | generation procedure in the software development system concerning embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Software development system 3 1st memory | storage means, 2nd memory | storage means 4 Processing means 6, 7 Process definition means 8 Search means, Storage means

Claims (3)

A software development system that develops software through a plurality of hierarchical processes,
First storage means for storing a document or source code in its own process based on a first keyword assigned to the document or source code in each process;
Second storage means for storing a document or source code of a higher-level process that is affected by a modification to the document or source code in its own process based on a second keyword given to the document or source code in each process;
A process definition means for defining a relationship between a document or source code in each process and a document or source code in a sub-process of the process;
The document or source code affected by the modification to the document or source code in any process is searched based on the second keyword for the document or source code in the upper process, and the document in the lower process Alternatively, search means for searching for source code based on the process definition means,
A software development system comprising: A first version number which is given to a document or source code in each process and updated whenever the document or source code is modified;
A second version number which is given to the first keyword and is updated when the modification of all documents or source code affected by the modification to the document or source code is completed;
Further comprising
2. The software development system according to claim 1, wherein the search means performs the search process triggered by a difference between the first version number and the second version number. Each process further comprises a plurality of sub-processes, which are given to the document or source code in each sub-process and identify a sub-process,
Further comprising
The first storage means stores a document or source code in each small process in the own process based on the process identifier,
The search means searches for a document or source code affected by a modification to a document or source code in any process based on the process identifier for the document or source code of each small process in the process. The software development system according to claim 1, wherein the software development system is a software development system.

Images