JP2007122135A - Development support device, development support method and development support program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To support the development of software by notifying any other deliverable affected by the corrected deliverable in each stage of a development process. <P>SOLUTION: This development support method is provided to support the development of such a deliverable as a request description document in which the request of software is described, a design model prepared from the request description document and a program code prepared from the design model. A computer is characterized to perform a procedure for storing the correspondence information of mutual deliverables in a storage part; a correction accepting procedure for accepting the input of the deliverable to be corrected; a correction tracing procedure for tracing the correspondence information of the deliverables stored in the storage procedure from the product accepted by the correction accepting procedure as a start point in order to trace the other deliverables affected by the product to be corrected; and a correction notification procedure for notifying the deliverable traced by the correction tracing procedure. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a software development support apparatus, a development support method, and a development support program.

  The software development process is a multi-stage process separated by each created product, such as creating a requirement description document, creating a design model from the requirement description document, and creating program code from the design model. I'm becoming. The request description document, the design model, and the program code are described in a format that is easy for humans to understand. Regarding the creation of these deliverables, several mechanisms have been proposed for creating them in part by a computer.

  First, as a method for creating a design model from a software requirement description document, for example, there is an object-oriented design support apparatus described in Patent Document 1. This is a requirement description document, and the correspondence between the use case scenario syntax, which is a notation of UML (Unified Model Language), and the syntax of the software design model is defined in advance. Conversion is realized.

Next, as a method for creating a program code from a design model, there is a model-driven development method as shown in Non-Patent Document 1. In these methods, first, a design model that does not depend on the development platform is converted into a design model that depends on the development platform, and further, a design model that depends on the development platform is converted into program code. For the conversion, meta information of the design model and a conversion rule between the meta information are used.
JP-A-10-240510 By David S. Frankel, “Model Driven Architecture (TM)”, John Wiley & Sons Inc, ISBN: 0471319201

  Note that the creators of deliverables at each stage of the development process often differ from one expert to another. For example, a customer creates a requirement description document, a system engineer creates a design model, and a programmer creates a program code. Here, when any of the deliverables is corrected, the correction also affects other related deliverables. For example, when one function is added to the requirement description document, it is necessary to modify the added function to the design model created from the requirement description document and the program code created from the design model. Become.

  Note that the automatically created product does not operate by itself, such as a function name in a program code. For example, the programmer completes the program code by supplementing the program code with the contents of the function corresponding to the function name based on the function name of the automatically generated program code. Therefore, the program code is not completed simply by applying the automatic product creation process to the latest corrected product.

  Therefore, the system engineer modifies the design model affected by the modified requirement description document, and the programmer modifies the program code influenced by the modified design model. Here, the system engineer needs to know the design model affected by the corrected requirement description document as the correction target, and the programmer needs to know the program code affected by the corrected design model as the correction target. However, the above-described automatic creation of a conventional product cannot present a correction target. Therefore, for example, it has been difficult for a system engineer and a programmer to reflect the correction of the request description document by the customer in the deliverable.

  Therefore, the present invention solves the above-mentioned problems and supports the development of software by notifying other deliverables affected by the corrected deliverable for the deliverables at each stage of the development process. Main purpose.

  The present invention is a development support apparatus that supports the development of a requirement description document that describes software requirements, a design model created from the requirement description document, and a product that is a program code created from the design model. Stored in the storage unit, starting from the storage unit that stores the product and correspondence information between the products, the correction reception unit that receives input of the product to be corrected, and the product received by the correction reception unit By tracking the correspondence information between the deliverables, a correction tracking unit that tracks other deliverables affected by the corrective product, and a correction notification unit that notifies the deliverable tracked by the correction tracking unit, It is characterized by having. Other means will be described later.

  According to the present invention, it is possible to track the influence spread range when each content after generation is corrected. This reduces the difference in recognition between the request provider (customer) and the developer and omissions in specifications, and improves the quality of software.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings using an example of Web application development.

  FIG. 1 shows the overall work flow of the software development support method in this embodiment. First, the developer creates a request description document that defines software specifications (step 101). The system converts the request description document created by the developer into the first design model using the first conversion rule 121 (step 102). At this time, the system records the conversion history as the first conversion history 131 in the database.

  After the first conversion is completed, the system uses the request-second conversion correspondence rule 122 to associate the element of the first design model with the second conversion rule 123 (step 104). At this time, the system records the association history as a request-second conversion correspondence history 132 in the database.

  Next, the system refers to the correspondence relationship between the first design model and the second conversion rule 123 performed in step 104, and converts the first design model into the second design model using the second conversion rule 123 ( Step 105). At this time, the system records the conversion history in the database as the second conversion history 133.

  The system repeats step 104 and step 105 by incrementing n by 1 until it reaches N (step 103), and the developer designs as needed while monitoring the conversion process presented by the system. The model can be modified. The developer obtains a program code as a final design model (step 106). After acquiring the program code, the developer activates the application by deploying the program code in the execution environment, and evaluates the specification implementation (step 107).

  In response to the evaluation result of the specification realization, the application acquired up to step 106 is corrected below.

  First, the developer modifies any of the request description document, the design model, and the program code (step 109). The system detects a modification by the developer, detects other development artifacts that may be affected by the modification, and notifies the developer (step 110).

  The developer confirms the development product notified by the system, and performs correction work necessary for matching with the correction (step 111). The developer repeats step 109 to step 111 (step 108), and completes the correction of the entire application while tracking the correction work required by the correction work required by the correction.

  FIG. 2 shows a case where there is information that can be imported from the external system 221 in the overall workflow of the software development support method described in FIG.

  First, when there is an existing request description document in the external system 221, the developer imports the request description document from the external system (step 201). If there is an existing first design model in the external system 221, the developer uses a user interface provided by the system to associate the request description document with the existing first design model (step 202). At this time, the system records the association made by the developer as the first (nth) conversion history 231. Thereafter, Step 103 to Step 106 in FIG. 1 are executed.

  By performing the work as described above, even when there is an existing requirement description document or design model, the development can proceed in the same manner as the overall work flow shown in FIG.

  FIG. 3 is a block diagram showing the software configuration of the present embodiment, and shows an example in which three-stage conversion is performed. Here, the third design model corresponds to a program code which is software implementation.

  First, the software in the present embodiment includes a requirement description document management processing unit 301 having a requirement description document DB 311, a first design model management processing unit 302 having a first design model DB 312, and a second design model having a second design model DB 313. A management processing unit 303 and a program code management processing unit 304 having a program code DB 314 are included. In addition, a first conversion processing unit 321 that converts the request description document into the first design model, a second conversion processing unit 322 that converts the first design model into the second design model, and a third that converts the second design model into program code. It has a conversion processing unit 323.

  Each conversion processing unit includes a first conversion rule 331 that defines a conversion method, a second conversion rule 333, a third conversion rule 335, a first conversion history 332 that records a conversion history, a second conversion history 334, It has 3 conversion history 336. The request description document management processing unit 301 also makes a request-second conversion correspondence rule 351 in which the application relation of the second conversion rule to the syntax pattern of the request description document is ruled, and a request-second conversion application that is an application history thereof. Has a history 352.

  The request description document management processing unit 301, the first design model management processing unit 302, and the second design model management processing unit 303 each have a user interface 341 for developers. The program code converted by the third conversion processing unit and stored in the program code DB 314 is deployed to the application storage DB 315 of the application management processing unit 305 by the deployment management processing unit 324 so that it can be evaluated by the user interface 342 for evaluation. become.

  FIG. 4 is a block diagram showing a hardware configuration of the present embodiment. The computer has a CPU 401, a main storage device 402, and a network connection device 403 as internal components, and has a display 404, an external storage device 405, and data input means 406 such as a keyboard and a mouse as external devices. When operating this embodiment in a network environment, the network connection device 403 is connected to an external network.

  FIG. 5 shows an example of converting the request description document 501 into the first design model 511 based on the first conversion rule 331. The request description document 501 includes a request ID 502, a request name 503, and a request description 504 configured in order by a step number. In the present embodiment, the first design model 511 is a user information model 512 that represents data and entities of software. However, the expression method is arbitrary as long as the first design model 511 in this embodiment is a model that expresses software specifications that do not depend on the platform of the application to be generated.

  The description 504 of requests configured in order according to step numbers is an approach for extracting syntax patterns as shown in FIGS. 8 and 10 to be described later by language processing from those described in natural language without restriction as shown in FIG. Either approach may be taken to make it easier to extract syntax patterns by restricting the description method from the stage when the developer creates the requirement description document.

  Further, the first design model 511 is added with the correspondence relationship to the second conversion rule determined in the operation step 104 shown in FIG. 1 as a pattern name 513 enclosed in << >>.

  When this embodiment is realized as a software development support tool, FIG. 5 shows a tool screen of the user interface 341 provided to the developer by the request description document management processing unit 301 and the first design model management processing unit 302 shown in FIG. It is a conceptual diagram corresponding to

  FIG. 6 is an example of converting the first design model 601 to the second design model 611 based on the second conversion rule 333. While the first design model 601 is configured only with information that does not depend on the platform of the application to be generated, the second design model 611 also has information that depends on the platform of the application to be generated. In FIG. 6, the first design model representing the user information 602 with the pattern name 603 is characterized by platform-specific information such as the Web application 612 and the database system 613 via the second conversion rule 333.

  Further, the second design model 611 is added with the correspondence relationship to the third conversion rule determined in the operation step 104 shown in FIG. 1 as a pattern name 614 enclosed in << >>. However, in the example of FIG. 6, since the third design model corresponds to a program code, the correspondence between the requirement description document and the conversion rule is not derived, and the type of the second design model defined in advance is a pattern. It is added as a name. In FIG. 6, << hoge >> is abbreviated as an example of the pattern name 614.

  When this embodiment is realized as a software development support tool, FIG. 6 shows a tool of the user interface 341 provided to the developer by the first design model management processing unit 302 and the second design model management processing unit 303 described in FIG. It is a conceptual diagram equivalent to a screen

  FIG. 7 is an example of converting the second design model 701 into the program code 711 based on the third conversion rule 335. The second design model 701 is directly associated with a file 712 that is a program implementation, a package, and a table 713 of a relational database. The second design model 701 is a model 702 to which a pattern name 704 is attached, and the correspondence relationship is held by the third conversion rule 335.

  When this embodiment is realized as a software development support tool, FIG. 7 shows a tool screen of the user interface 341 provided to the developer by the second design model management processing unit 303 and the program code management processing unit 304 described in FIG. It is an equivalent conceptual diagram

  FIG. 8 shows a request-second conversion correspondence rule 351 that is used by the first conversion processing unit 321 and is a feature of this embodiment. The request-second conversion correspondence rule 351 includes a rule ID 811 that uniquely indicates the request-second conversion correspondence rule 351, a syntax pattern 814 of a request description that includes a set of a vocabulary type 812 and its value 813 for each step of the request description document, By the ID 815 that uniquely indicates the first conversion rule assumed (relevant) by the request-second conversion correspondence rule 351, and the second conversion rule name 816 that uniquely indicates the second conversion rule related to the syntax pattern 814 of the request description. Express. According to the request-second conversion correspondence rule 351, in this embodiment, information for adding the second conversion rule to the first design model is extracted from the request description document, and the first conversion to the third conversion are seamlessly related. It becomes possible to attach.

  FIG. 9 shows a request-second conversion correspondence history 352 used by the request description document management processing unit 301. The request-second conversion correspondence history 352 records an application history when the request-second conversion correspondence rule 351 is actually applied, and the request description to which the request-second conversion correspondence rule 351 is applied is uniquely specified. A request ID 911 and a step ID 912 are shown, a conversion rule name 913 that uniquely indicates the second conversion rule to be applied, and an application target model ID 914 that uniquely indicates the first design model to be applied.

  FIG. 10 shows the first conversion rule 331 used by the first conversion processing unit 321. The first conversion rule 331 is determined to be applied according to a rule ID 1011, a request description syntax pattern 1012 including a set of the vocabulary type 1013 and its value 1014 for each step of the request description document, and a request description step corresponding to the syntax pattern 1012. This is expressed by a conversion action 1015 and a dependency rule 1016 indicating a dependency relationship between the first conversion rules.

  Each rule defines that when the step of the requirement description document satisfies the requirement description syntax pattern 1012, the first design model indicated by the conversion action 1015 is output. In addition, since there may be a dependency relationship between rules, in this case, it is defined as a dependency rule 1016, and the first conversion processing unit 321 resolves the dependency relationship.

  FIG. 11 shows the first conversion history 332 used by the first conversion processing unit 321. The first conversion history 332 records an application history when the first conversion rule 331 is actually applied. A request ID 1111 and a step ID 1112 that uniquely indicate a request description corresponding to the syntax pattern of the first conversion rule 331. , An applied rule ID 1113 that uniquely indicates the applied first conversion rule, a model ID 1114 that uniquely indicates the first design model generated by the conversion, a type 1115 that indicates the granularity of the model such as a class and a method, and a name 1117 It consists of design model information 1116.

  FIG. 12 shows the second conversion rule 333 used by the second conversion processing unit 322. The second conversion rule 333 includes a rule ID 1211 and a conversion rule name 1212 that uniquely indicate the second conversion rule 333, an action type 1213 that is applied when the second conversion rule 333 is applied, and a post-conversion design that is converted or generated. The model 1214 and the second design model are represented by a conversion action 1216 that is a set of a post-conversion design model type 1215 indicating the characteristics of the second design model.

  Each rule defines the model configuration of the second design model converted from the first design model when the application pattern specified from the conversion rule name 1212 is applied to the first design model. Here, the post-conversion design model type 1215 is originally derived from the requirement description document. In this example, since the third design model corresponds to a program code, the correspondence relationship from the requirement description document to the conversion rule is derived. It is assumed that the model type of the second design model defined in advance is used.

  FIG. 13 shows the second conversion history 334 used by the second conversion processing unit 322. The second conversion history 334 records an application history when the second conversion rule 333 is actually applied. The second conversion history 334 uniquely identifies the class ID 1311 that uniquely indicates the first design model before conversion, and the applied second conversion rule is unique. And the post-conversion design model information 1317 that is a set of the ID 1314, the name 1315, and the model type 1316 that uniquely indicates the second design model after conversion.

  FIG. 14 shows the third conversion rule 335 used by the third conversion processing unit 323. The third conversion rule 335 includes a rule ID 1411 that uniquely indicates the third conversion rule 335, a model type 1412 that indicates an attribute of the second design model before conversion, and a template file prepared in advance for application in correspondence with the model type. 1413 and variable parameter 1414. The template file 1413 is a program code template prepared for each model type 1412 and has a customizable portion as a variable parameter 1414 in advance. In the third conversion rule 335, the value of the variable parameter 1414 can be defined as rule information.

  FIG. 15 shows a third conversion history 336 used by the third conversion processing unit 323. The third conversion history 336 records an application history when the third conversion rule 335 is actually applied, and a model ID 1511 and a model name for uniquely determining the second design model to which the third conversion rule 335 is applied. 1512, an application rule ID 1513 uniquely indicating the applied third conversion rule 335, and a program code generation file 1514 generated as a result of the application.

  FIG. 16 shows the correspondence between the first conversion history 332, the second conversion history 334, the third conversion history 336, and the request-second conversion application history 352 in a simple example. In the figure, the first conversion history 332 and the request-second conversion application history 352 include a link 1601 based on the request ID and the step ID, and a link 1602 based on the generation model ID.

  The request-second conversion application history 352 and the second conversion history 334 include a link 1603 based on the application target model ID and a link 1604 based on the application pattern. Further, the second conversion history 334 and the third conversion history 336 have a link 1606 based on the generated model ID. In this embodiment, the traceability of a requirement description document, a plurality of design models with different analysis levels, and program code is established by tracing these links. Further, there are a link 1605 and a link 1607. A link 1605 indicates correspondence information between design models, and a link 1607 indicates correspondence information between design models and program codes.

  Based on the above description, a screen example of the development user interface 341 used by the developer will be described.

  FIG. 17 is a request description document management GUI provided to the development user interface 341 by the request description document management processing unit 301. The first design model, the second design model, and the program code that affect the selected request item are modified. This is a screen 1701 used when the requested scenario is corrected while referring to it.

  A screen 1701 displays a request item list frame 1711 for displaying a list of request scenario items for software under development, a menu bar 1712, a request step list frame 1713 for displaying a step of a request item selected from the list, and a request scenario. It comprises a reference information display frame 1714 for displaying reference information for correction.

  The request step list frame 1713 counts up the number of steps ID 1721, scenario document 1722, the first design model, the second design model, and the number of modifications that can affect the request description document for each program code. A table having columns 1723 to 1725 to be displayed is displayed. The reference information display frame 1714 displays details of correction of any of the first design model, the second design model, and the program code selected from the table columns 1723 to 1725 of the request step list frame 1713.

  The developer confirms the first design model, the second design model, and the modification information 1732 of the program code 1731 displayed in the reference information display frame 1714, and directly updates or corrects the corresponding request step of the appropriate request description document. Can be added / deleted 1733.

  FIG. 18 is a request description document management GUI provided to the development user interface 341 by the request description document management processing unit 301 as in FIG. 17, and the first design model in which the modification to the selected request item affects the first design model. 2 is a screen 1801 used when tracking a design model and program code.

  The screen 1801 includes a request item list frame 1811, a request step list frame 1813, and a reference information display frame 1814, as in FIG. The request step list frame 1813 counts up and displays the number of models and modules affected by the modification to the request item for each of the step ID 1821, the scenario document 1822, the first design model, the second design model, and the program code. A table having columns 1823 to 1825 to be displayed is displayed.

  Further, the reference information display frame 1814 includes an index 1831 and a trace execution button 1832 to the influence spread target of any of the first design model, the second design model, and the program code selected from the table columns 1823 to 1825 of the request step list frame 1813. Is displayed. The developer can track the first design model, the second design model, and the program code, which are affected by the modification to the requirement description made in FIG. 17, with reference to FIG.

  Note that switching between FIG. 17 and FIG. 18 is performed by menu bars 1712 and 1812 which are common to both screens.

  FIG. 19 is a program code management GUI provided to the development user interface 341 by the program code management processing unit 304, and refers to the request description, the first design model, and the modification of the second design model that affect the selected program module. The screen 1901 is used when the program code is modified.

  A screen 1901 includes a module list frame 1911 for displaying a list of modules in software under development, a code display / editing frame 1912 for displaying or editing the implementation code of a module selected from the list, a menu bar 1913, and a program code correction. It consists of a reference information display frame 1914 for displaying the reference information when doing so.

  The reference information display frame 1914 displays the name of the selected module and method 1931, the index 1932 to the correction information related to the selected module, and the details before and after correction 1933 of the correction information selected from the index 1932. To do.

  Similar information can also be inserted as comment sentences 1923 and 1924 in the code 1921 or the influence range 1922 displayed in the code display edit frame 1913. The developer can perform appropriate code correction while confirming the request description, the first design model, and the second design model correction information 1933 displayed in the reference information display frame 1914.

  FIG. 20 is a program code management GUI provided to the development user interface 341 by the program code management processing unit 304 as in FIG. 19. The request description that the modification to the selected program code affects, the first design model, This is a screen 2001 used when tracking the second design model.

  The screen 2001 includes a module list frame 2011, a code display editing frame 2012, and a reference information display frame 2014, as in FIG. The reference information display frame 2014 includes a selected program and method name 2031, a requirement description that is affected when the selected module is modified, the first design model, the index 2032 to the second design model, and a trace execution button 2033. Is displayed. The developer can track the requirement description, the first design model, and the second design model that are affected by the modification to the program code performed in FIG. 19 with reference to FIG.

  Note that switching between FIGS. 19 and 20 is performed by menu bars 1913 and 2013 that both screens have in common.

  FIG. 21 is a configuration diagram in which means relating to modification to a product is added to the configuration of FIG. 3.

  The request description document input unit 10 receives an input of a request description document in which a software request is described in a natural language. The request description document storage unit 12 stores a request description document.

  The design model input unit 20 receives an input of a design model as an import. The design model may be constituted by a multi-stage model with different analysis levels. The design model conversion unit 22 converts a request description document into a design model. The conversion is performed based on a conversion rule applied to the request description document. The design model storage unit 24 stores a design model. The design model storage unit 24 also stores the correspondence between the request description document before conversion and the design model after conversion. Consistency and traceability are maintained by referring to this correspondence.

  The program code input unit 30 receives an input of a program code that is software implementation as an import. The program code conversion unit 32 converts the design model into a program code. The conversion is performed based on a conversion rule applied to the design model. The program code storage unit 34 stores program codes. The program code storage unit 34 also stores the correspondence between the design model before conversion and the program code after conversion.

  The correction reception unit 40 receives a correction to an existing product from the user.

  The correction tracking unit 42 tracks a product affected by the received correction. The tracking is realized by following the correspondence relationship between the products stored in the design model storage unit 24 and the program code storage unit 34 as a link. The opportunity for tracking is before correction (pre-execution) or after correction (post-execution). The correction tracking unit 42 repeatedly performs tracking to find a product that needs a new correction by performing a correction required by a correction performed by the developer in the past.

  The correction notification unit 44 notifies the user of the deliverables affected by the correction. When the developer tries to separately correct the product affected by the correction, the developer is notified that there is a possibility that information inconsistency may occur due to the correction made earlier.

  The design model conversion unit 22 and the program code conversion unit 32 create a product for each product after conversion from before conversion. This improves the software development productivity by automating the design model and program code generation work from the requirement description document.

  The design model conversion unit 22 may refer to non-functional requirements described in the request description document. A non-functional requirement is an improved desire for a default function, rather than adding a function. For example, adding a function for printing new information on the print screen is a functional requirement, and improving the printing speed on the print screen is a non-functional requirement for improving performance.

  As a means for reflecting the non-functional requirements in the product, for example, when the product is a design model, a design pattern of the design model is selected. Design patterns are the basic framework of program code. Even when the same function is implemented, if the design pattern is different, the implemented program code may differ greatly in appearance.

  There are various design patterns, such as those having a small amount of program code and excellent maintainability, and those having a large processing amount but a high processing speed. Therefore, correspondence information between the non-functional requirements and the design pattern may be defined in advance, and the design pattern of the design model may be specified from the non-functional requirements described in the request description document based on the correspondence information. Corresponding information includes, for example, non-functional requirements for suppressing development costs and correspondence of design patterns with a small amount of program code. This can support creation of a product that is faithful to the requirement description document.

  FIG. 22 is an explanatory diagram of tag information attached to the design model. First, the design model conversion unit 22 attaches a request reflected in the program code among the requests described in the request description document to the design model as tag information. Next, the program code conversion unit 32 converts the request into the program code with reference to the tag information. Thereby, the request described in the request description document can be accurately reflected in the program code. As a comparative example, if the means for converting a requirement description document to a design model and the means for converting a design model to a program code are simply combined, the request reflected in the program code described in the requirement description document It will fall out when converted to a model.

  FIG. 23 is an explanatory diagram showing the number of stages of the design model. FIG. 23A shows a one-stage design model, and FIG. 23B shows a three-stage design model. The one-stage design model is excellent in processing speed because the number of conversions is small. The three-stage design model makes it easy to combine a plurality of design models of the same type into one design model, and the memory usage can be suppressed.

  FIGS. 24 to 26 are explanatory diagrams showing how the correction tracking unit 42 tracks the correction received by the correction receiving unit 40. FIG. 24 shows the modification to the requirement description document, FIG. 25 shows the modification to the design model, and FIG. 26 shows the modification to the program code. In each figure, a node indicates a product (request description document, design model, program code). A link between nodes indicates correspondence information regarding conversion.

  The correction to the request description document will be described with reference to FIG. When the correction receiving unit 40 receives a correction to the request description document R1, the correction tracking unit 42 tracks the linked design models C1 and C2 from the request description document R1. The correction tracking unit 42 tracks linked program codes P1, P2 from the tracked design models C1, C2.

  FIG. 24B is an explanatory diagram showing how the nodes tracked by FIG. 24A are recursively tracked. For the tracked node, the correction tracking unit 42 tracks the link in the direction opposite to that in FIG. 24A for the program code P2 having a link other than the link used for tracking. Thereby, the correction tracking unit 42 acquires the design model C3 and the request description document R3 as the influence range.

  With reference to FIG. 25A, correction to the design model will be described. When the correction receiving unit 40 receives a correction to the design model C1, the correction tracking unit 42 tracks the request description document R1 linked to the design model C1 and the program codes P1 and P2.

  FIG. 25B is an explanatory diagram showing a state in which the node tracked by FIG. 25A is recursively tracked. For the tracked node, the correction tracking unit 42 tracks the link in the opposite direction to FIG. 25A for the request description document R1 having a link other than the link used for tracking and the program code P2. Thereby, the correction tracking part 42 acquires the design models C2 and C3 as an influence range.

  With reference to Fig.26 (a), the correction to a program code is demonstrated. When the correction receiving unit 40 receives a correction to the program code P1, the correction tracking unit 42 tracks the design model C1 with a link from the program code P1. The correction tracking unit 42 tracks a request description document R1 with a link from the tracked design model C1.

  FIG. 26B is an explanatory diagram showing a state in which the node tracked by FIG. 24A is recursively tracked. For the tracked node, the correction tracking unit 42 tracks the link in the direction opposite to that in FIG. 24A for the request description document R1 having a link other than the link used for tracking. Thereby, the correction tracking part 42 acquires the design model C2 and the program code P2 as an influence range.

  As shown in FIG. 24 to FIG. 26, the node affected by the corrected node is acquired by following the links one after another from the corrected node. As a result, the user can know other deliverables affected by the corrected deliverable, so that the inconsistency of the correction contents between the deliverables can be confirmed in advance of the correction.

It is a flowchart which shows the whole operation | work regarding one Embodiment of this invention. It is a flowchart which shows the whole operation | work when there exists the existing information regarding one Embodiment of this invention. It is a block diagram which shows the software structure regarding one Embodiment of this invention. It is a block diagram which shows the hardware constitutions regarding one Embodiment of this invention. It is explanatory drawing which shows the flow of the 1st conversion regarding one Embodiment of this invention. It is explanatory drawing which shows the flow of the 2nd conversion regarding one Embodiment of this invention. It is explanatory drawing which shows the flow of the 3rd conversion regarding one Embodiment of this invention. It is a block diagram which shows the request | requirement-2nd conversion corresponding | compatible rule regarding one Embodiment of this invention. It is a block diagram which shows the request | requirement-2nd conversion application log | history regarding one Embodiment of this invention. It is a block diagram which shows the 1st conversion rule regarding one Embodiment of this invention. It is a block diagram which shows the 1st conversion log | history regarding one Embodiment of this invention. It is a block diagram which shows the 2nd conversion rule regarding one Embodiment of this invention. It is a block diagram which shows the 2nd conversion log | history regarding one Embodiment of this invention. It is a block diagram which shows the 3rd conversion rule regarding one Embodiment of this invention. It is a block diagram which shows the 3rd conversion log | history regarding one Embodiment of this invention. It is explanatory drawing which shows the example of the conversion trace regarding one Embodiment of this invention. It is a screen figure which shows the requirement description document management GUI (revision of a requirement description document) regarding one Embodiment of this invention. It is a screen figure which shows the request description document management GUI (tracking after correction) regarding one Embodiment of this invention. It is a screen figure which shows the program code management GUI (program code correction) regarding one Embodiment of this invention. It is a screen figure which shows the program code management GUI (tracking after correction) regarding one Embodiment of this invention. It is a block diagram which shows the software structure which added the means regarding correction to the product regarding one Embodiment of this invention. It is explanatory drawing which shows the tag information attached | subjected to the design model regarding one Embodiment of this invention. It is explanatory drawing which shows the number of steps of the design model regarding one Embodiment of this invention. It is explanatory drawing which shows the correction to the request description document regarding one Embodiment of this invention. It is explanatory drawing which shows the correction to the design model regarding one Embodiment of this invention. It is explanatory drawing which shows the correction to the program code regarding one Embodiment of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Requirement description document input part 12 Requirement description document storage part 20 Design model input part 22 Design model conversion part 24 Design model storage part 30 Program code input part 32 Program code conversion part 34 Program code storage part 40 Correction reception part 42 Correction tracking part 44 Correction notification section

Claims (16)

A development support apparatus that supports development of a requirement description document that describes software requirements, a design model created from the requirement description document, and a product that is a program code created from the design model,
A storage unit that stores deliverables and correspondence information between deliverables;
A correction accepting unit that receives input of a deliverable to be corrected;
A correction tracking unit that tracks other products affected by the product to be corrected by tracing the correspondence information between the products stored in the storage unit, starting from the product received by the correction receiving unit,
A correction notification unit for notifying the deliverable tracked by the correction tracking unit;
A development support apparatus characterized by comprising: A request description document input unit for receiving input of a request description document;
A design model conversion unit that converts the request description document input by the request description document input unit into a design model based on a conversion rule applied to the request description document;
A program code conversion unit that converts the design model converted by the design model conversion unit into a program code based on a conversion rule applied to the design model;
The storage unit is correspondence information when the request description document is converted from the design model to the design model by the design model conversion unit, and correspondence when the program code conversion unit is converted from the design model to the program code. The development support apparatus according to claim 1, wherein the information is stored as correspondence information between deliverables. The request description document input unit for receiving input of a request description document;
A design model input unit for receiving an input of a design model corresponding to the request description document;
A program code input unit that receives an input of a program code corresponding to the design model,
The storage unit includes correspondence information when the requirement description document and the design model are input in the design model input unit, and correspondence when the design model and the program code are input in the program code input unit. The development support apparatus according to claim 1, wherein the information is stored as correspondence information between deliverables. The correction receiving unit receives an input of correction of a predetermined request description document,
The correction tracking unit refers to correspondence information between deliverables stored in the storage unit, tracks a design model corresponding to a predetermined requirement description document, and a program code corresponding to the design model,
The development support apparatus according to any one of claims 1 to 3, wherein the correction notification unit notifies the design model and the program code tracked by the correction tracking unit. The correction tracking unit starts from a program code tracked from a predetermined request description document, tracks a design model corresponding to the program code of the start point, and a request description document corresponding to the design model,
The development support apparatus according to claim 4, wherein the correction notification unit notifies the request description document tracked by the correction tracking unit. The correction receiving unit receives an input of correction of a predetermined design model,
The correction tracking unit refers to correspondence information between deliverables stored in the storage unit, tracks a requirement description document corresponding to a predetermined design model, and a program code corresponding to the predetermined design model,
The development support apparatus according to claim 1, wherein the correction notification unit notifies the request description document and the program code tracked by the correction tracking unit. The modification tracking unit traces a design model corresponding to the request description document of the starting point and a design model corresponding to the program code of the starting point from the request description document tracked from the predetermined request description document and the program code. And
The development support apparatus according to claim 6, wherein the correction notification unit notifies the design model tracked by the correction tracking unit. The correction reception unit receives an input of correction of a predetermined program code,
The correction tracking unit refers to correspondence information between deliverables stored in the storage unit, tracks a design model corresponding to a predetermined program code, and a requirement description document corresponding to the design model,
The development support apparatus according to claim 1, wherein the correction notification unit notifies the design model and the request description document tracked by the correction tracking unit. The modification tracking unit starts from a request description document tracked from a predetermined program code, tracks a design model corresponding to the request description document of the starting point, and a program code corresponding to the design model,
The development support apparatus according to claim 8, wherein the correction notification unit notifies the program code tracked by the correction tracking unit. The correction reception unit receives an input of correction of a predetermined deliverable,
10. The correction notification unit, when a previously notified product matches a predetermined product received by the correction receiving unit, warns that as a correction conflict. The development support apparatus according to any one of the above.   The development support apparatus includes a display for comparing the content before correction and the content after correction for the product to be corrected received by the correction reception unit, and means for performing display of the product notified by the correction notification unit. The development support apparatus according to claim 1, further comprising: The correction reception unit receives input of a deliverable before correction,
The correction tracking unit considers that the product before correction received by the correction reception unit has been corrected, tracks other artifacts that are affected,
The development support apparatus according to claim 1, wherein the correction notification unit notifies the product tracked by the correction tracking unit before the product is corrected. A development support method for supporting development of a requirement description document describing a requirement of software, a design model created from the requirement description document, and a deliverable that is a program code created from the design model,
Computer
A procedure for storing the product and correspondence information between the products in the storage unit;
A correction acceptance procedure for accepting input of a deliverable to be corrected;
A correction tracking procedure for tracking other artifacts affected by the artifact to be corrected by tracing the correspondence information between the artifacts stored in the storage procedure starting from the artifact received by the correction reception procedure;
A correction notification procedure for notifying the deliverable tracked by the correction tracking procedure;
A development support method characterized by executing Computer
A request description document input procedure for receiving an input of a request description document;
A design model conversion procedure for converting the request description document input by the request description document input procedure into a design model based on a conversion rule applied to the request description document;
Executing a program code conversion procedure for converting the design model converted by the design model conversion procedure into a program code based on a conversion rule applied to the design model;
The storage unit is correspondence information when the requirement description document is converted to the design model in the design model conversion procedure, and correspondence when the design model is converted to the program code in the program code conversion procedure The development support method according to claim 13, wherein the information is stored as correspondence information between deliverables. Computer
The request description document input procedure for receiving input of a request description document;
A design model input procedure for receiving an input of a design model corresponding to the requirement description document;
A program code input procedure for receiving input of program code corresponding to the design model,
The storage unit includes correspondence information when the requirement description document and the design model are input in the design model input procedure, and correspondence when the design model and the program code are input in the program code input procedure. 14. The development support method according to claim 13, wherein the information is stored as correspondence information between deliverables. A development support program for causing a computer to execute the development support method according to any one of claims 13 to 15.

Images