JPH08147152A - Software specification reuse support device - Google Patents

Abstract

PURPOSE: To provide the software specification reuse support device which improves the productivity in the specification generating work for new software, which uses software specifications generated in the past, and improves the reliability of completed specifications. CONSTITUTION: A data base DB 3 where software specifications generated in the past, the generation history of these specifications, and relational information between specifications are stored, a means which uses specifications stored in the DB 3 to generate new specifications, a means which recognizes the present specification generation condition, a means which stores procedures of specification generation in the DB 3 as the generation history, a means which stores routes for search in the DB 3 as relational information in the DB 3, a means which narrows down the range of routes for search in the DB 3 in accordance with the specification generation condition, the generation history, and relational information, and a means which searches the DB 3 based on these narrowed-down routes are provided.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software specification reuse support device for supporting selection of specifications to be reused in the process of creating new software specifications while reusing existing specifications.

[0002]

2. Description of the Related Art A software specification reuse support device allows a user to reuse existing software specifications to newly develop software with high productivity and reliability.
A device used (hereinafter, a user refers to a person who newly creates specifications using an existing specification database). In the conventional specification reuse method in the software specification reuse support device, the focus is first on searching the specifications of software having similar specifications. Also,
In the general method of specification reuse, a template of specifications for each field is prepared, information is added based on this, and a new specification is created.

The specification search method searches for similar existing specifications based on the requirements of the software to be developed, from the viewpoint of the rough structure of functions and the number of similar terms appearing in the request sentence. Often. However, in the development of software in the same field, for example, in the case of customer systems for paperwork, the basic functions and terms used are almost the same even if the customer is different. , Searching the specification of similarity judgment by the number of terms used is not effective.

In addition, when information is added to a model to create a specification, it is difficult to prepare a model sufficiently and consistently for all work. In addition, when creating a new specification using a template, information is added or modified, but the information added or modified in this way is often important information in the creation of another specification. , There is no means for formalizing these information, and it is difficult to store them for the next reuse.

In addition, the existing specifications including the model specifications are often divided into a plurality of files or are made into parts. Various relationships such as relationships between terms, upper and lower relationships, and relationships with high similarity can be considered as the relationship between the specifications that are the parts. However, in the conventional specification reuse method, there is no mechanism for accumulating knowledge about the relationship between specifications (between parts) as know-how, and when modifying specifications or adding information,
It was unclear how a change of one part would be reflected in another part, and on the contrary, there was a problem that the reliability of the specification deteriorated. Further, in the conventional specification reuse method, there is no mechanism for accumulating know-how such as a creation procedure that is important for specification reuse. In other words, the focus was on which existing specification part to use, and there was a lack of perspective on how to use it. Therefore, the productivity may be reduced depending on how to use the parts and the procedure for creating the parts.

[0006] In addition, the repeated reuse often causes a change in the relationship between the specifications, and it is extremely difficult for the user to properly understand the relationship between the specifications and select the optimum reuse method. Met.

[0007]

As described above,
In the conventional software specification reuse support device, from the accumulated existing software specifications and component specifications, based on the requirements of the software to be developed, from the viewpoint of the rough structure of functions and the number of similar terms that appear. , It is only possible to search for similar specifications, and there is no support for the relationship between existing specifications or the usage of those specifications, so when developing new software, the existing specifications There were problems in terms of effective utilization, productivity in development, and reliability of the developed specifications.

The present invention has been made in consideration of the above circumstances, and recognizes the specification creation status of a user, and based on the past specification creation history and information on the relationship between specification parts, the existing specification database is used. By generating a search path as to how to determine the specification to be reused, and presenting it to the user to support the specification of the specification and specification parts to be reused or changed, and An object of the present invention is to provide a software specification reuse support device that improves productivity in specification creation work and improves reliability of a completed specification.

Further, the present invention has been made in consideration of the above circumstances, and in consideration of the user's specification creation status and in consideration of the user's purpose of reuse, the past specification creation history and specifications. By generating a guide for appropriate specification reuse from the information on the relationship between parts and presenting it to the user, support the determination of specifications and specification parts to be reused or changed, and reuse the specifications. Software specification reuse support device that supports the accumulation of know-how such as related creation procedures and related knowledge between specifications in a database, and improves productivity in software specification creation work and reliability of completed specifications. The purpose is to provide.

[0010]

A software reuse support apparatus according to the present invention is a database that accumulates software specifications created in the past, a creation history of the software specifications, and related information between the software specifications, and the database. Specification creating means for creating a new software specification by using the software specifications accumulated in, the recognition means for recognizing the current specification creating status by the specification creating means, and the specification created by the specification creating means. History creating means for accumulating a creation procedure in the database as a creation history, route creating means for accumulating a path for searching the database as related information in the database, the specification creation status, the creation history, the Search for software specifications stored in the database from related information A search path narrowing means to narrow the road, and having a specification database search means for searching for a software specification stored in the database based on the path narrowed down by the search path narrowing means. Preferably, the present invention further comprises a presenting means for presenting reusable software specification candidates based on the search result of the specification database searching means. Further, preferably, the presenting means, with respect to the presented reusable software specification candidates,
It is characterized by presenting an editing procedure.

Further, the software reuse support apparatus according to the present invention inputs the software specifications created in the past, the creation history of the software specifications created in the past, and the related information between the software specifications created in the past from the outside,
This is a software reuse support device for creating a new software specification by using this, and the software specification that has already been created is input from the outside and used to create a new software specification. Means and
Of the software specifications stored in the specification database based on the recognition means for recognizing the creation status by the editing means, the creation status, and the creation history and the related information related to the software specifications input from the outside. And a presenting means for presenting reusable software specification candidates. Preferably, the presenting means presents an editing procedure for the presented reusable software specification candidate.

[0012] Further, preferably, the creation history includes information describing a software specification name and a creation order of the software specification and, if necessary, information describing a usage relationship between other software specifications. It is characterized by

[0013] Further, it is preferable that the related information includes information describing two or more software specifications together with their software specification names and how they are related.

Further, the software reuse support apparatus according to the present invention comprises a database that stores software specifications created in the past, a creation history of the software specifications, and link information indicating the types of relationships between the software specifications, and The specification creating means for creating a new software specification using the software specifications accumulated in the database, the recognizing means for recognizing the current status of creating the specifications by the specification creating means, and the specification creating means are used. A history creating unit that stores a procedure for creating a specification in the database as a creation history, a software specification created by the specification creating unit, and a type of association between the software specification stored in the database as link information. Link information creation means to be stored in the database and the specifications Reuse guide generation means for generating guide information for reusing the software specifications accumulated in the database, based on the situation, the creation history, the link information, and the designated type of association and its priority. It is characterized by having.

[0015] Preferably, the type of the association can be arbitrarily designated by one or a plurality of types from the outside.

[0016] Further, preferably, the relation type is a creation history indicating that one software specification can be used to create the other software specification, and one software specification is corrected to the other software specification. A modification impact that indicates an influential relationship, a parent and child that indicates a higher-level / lower-level relationship between software specifications, a relationship that indicates a non-upper / lower-level relationship between software specifications, and both software specifications A common term is used to include at least one of the terms indicating a relationship.

Further, preferably, the reuse guide generation means generates a reusable software specification candidate as the guide information when the designated association type includes a creation history.

Further, preferably, when the designated association type includes a creation history, the reuse guide generating means uses a reusable software specification candidate and an editing procedure using the candidate as the guide information. It is characterized by generating.

Further, preferably, when a plurality of types of relations are designated, the reuse guide generation means outputs the guides generated corresponding to the respective types of relations in the order of designated priorities. Is characterized by.

Further, preferably, the creation history includes information describing a software specification name and a creation order of the software specification and, if necessary, information describing a usage relationship between other software specifications. It is characterized by

Also, preferably, the link information is 2
The above software specifications are characterized by including information describing both the names of the software specifications and how they are related.

Further, it is preferable that the apparatus further comprises means for editing the creation history and the link information accumulated in the database.

[0023]

In the software specification reuse support apparatus of the present invention, since the software specifications, the creation history of the software specifications, and the related information between the software specifications are stored in the database, the relationship in the specification database is clarified. Become. Since the specification database is searched based on the new specification creation status, the creation history, and the related information, it is effective for the user to list the next reusable specification candidate and present the next creation procedure. You can give a good guide.

Therefore, according to the present invention, the productivity of specification creation is improved, and the relationship between specifications is shown by the guide. Therefore, the range of influence of the correction contents is clarified, and the reliability of specification creation is improved. It has the effect.

Since the software specification reuse support apparatus of the present embodiment accumulates know-how such as past specification creation history and information on the relationship between specification parts, the relationship in the specification database becomes clear and The extent of the impact of the correction will be clarified. Then, in the specification creation process in software development, the user recognizes the user's specification creation status and considers the user's purpose of reuse, and re-creates it from know-how such as past specification creation history and information on the relationship between specification parts. Specifications and specification parts to be reused or changed by generating a guide for appropriate specification reuse, such as information on the specifications and creation procedures of specifications that can be used, or information on the relationship between specifications, and presenting it to the user. Can assist in decisions such as Further, it is possible to support the work of accumulating in the database the know-how such as the creation procedure when reusing the specifications and the related knowledge between the specifications, and freely adding / correcting.

Therefore, according to the present invention, it is possible to effectively use the specifications, and it is possible to improve the productivity in the software specification creation work and the reliability of the completed specifications.

[0027]

Embodiments of the present invention will be described below with reference to the drawings.

In the present embodiment, the specifications include a business function hierarchical structure list, a screen transition diagram, a screen layout, a form layout, a file relationship diagram, a screen-file relationship, a performance requirement, a failure countermeasure, and the like. Specifications of each type are
It is composed of multiple fragments. In addition to the above specifications, the present invention can be applied to anything such as text, images, and graphics as long as it is a set of data having a file name.

(First Embodiment) FIG. 1 is a block diagram of a software specification reuse support device according to a first embodiment of the present invention. As shown in the figure, the software specification reuse support apparatus of the present embodiment comprises an input / output unit 1, a processing unit 2 and a database 3. The processing unit 2 advances the processing while accessing the database 3 by an instruction / data input from the input / output unit 1. Arrows in FIG. 1 indicate flows of data and control signals.

The input / output unit 1 is composed of a keyboard which is an input device, a CRT which is an output device, and the like, and can input and display software specifications. A so-called mouse can be used or used as the input device. As the output device, a printer can be used or used in combination.

The processing unit 2 includes the user interface unit 1
0, a specification editor unit 11, a specification database search support unit 12, a user recognition unit 13, a search route narrowing unit 14, a history creation unit 15, and a route creation support unit 16. Processing unit 2
Is configured using, for example, a CPU and a memory, and the function is provided by software processing.

The database 3 is the specification database 3
a, a creation history database 3b, and a search route database 3c. The specification database 3 will be described in detail later.
a is a database for accumulating specifications created in the past, a creation history database 3b is a database for accumulating creation history that is a procedure of specifications created in the past, and a search route database 3c is a specification This is a database that stores search paths for searching the database 3a.

The user interface section 10 accesses the database 3 and displays the contents on the input / output section 1. In addition, the specification editor unit 11, the specification database search support unit 12, the history creation unit 15, and the route creation support unit 16 are activated, terminated, and displayed on the input / output unit 1 as execution contents.

The specification editor unit 11 is for supporting the description of the specifications that make up the software. The past specification fragments described in the specification database 3a can be read, edited, and saved.

Here, the description of the specifications forming the software is, for example, as shown in FIGS. 2, 3 and 4, and FIG. 2 is a description of the result of dividing the work according to the flow of time. FIG. 3 shows an example of a description of a process flow of a divided work by a screen transition diagram, and FIG. 4 shows an example of a description of correspondence between screen and file processes.

FIG. 2 is an example of a business bird's-eye view in which a plurality of jobs having a time-sequential relation related to office work are described by dividing them into jobs for each time zone, and jobs in each time zone are hierarchically described. And is described using the "gift system" as an example. For example, the time block of “daily processing” in the time block of “season work” is divided into three blocks of “daily start processing”, “daytime work”, and “daily end processing” in different time zones. In addition, the time block of “day-time work” among these is divided into four blocks, “order entry”, “order correction”, “master maintenance”, and “online transmission”, to perform these tasks. It shows that it can be selected appropriately and defined.

FIG. 3 is an example of a screen transition diagram that defines the flow of work, and is described using the “gift system” as an example, as in FIG. This screen transition diagram has screen states indicated by circles and transitions indicated by arrows. Describe the name of the screen state near the circle that represents the screen state, and the name of the "event" that causes the screen transition near the arrow that represents the transition.
Describe the name of the "action" caused by the event. By using such a screen transition diagram, the user can define the screen transition of the application when performing "order entry" as follows. That is, first, when the event of inputting the "application number" occurs from the initial screen "Preliminary list inquiry", the "search" operation with the "application number" as the input attribute and "customer information" as the output attribute. When the event of inputting "phone number" occurs, "Search" operation with "phone number" as the input attribute and "customer information" as the output attribute is performed, and then the screen state of "requester input" appears. Can be defined as transition to. It is possible to define that the screen transition is performed in the same manner in other screen states as well, and finally that the screen state transitions to "input individual slip".

FIG. 4 is an example of a method connection diagram that defines the relationship between the screen method and the file method.
Similar to the above, the description is made using the "gift system" as an example. This association has one screen method and a list of file methods. One screen method is described in the left column and the file method list is described in the right column of the relationship diagram. The user uses the "Search list" method in the "Customer master" file for the "Search" method with "Phone number" as the input attribute and "Customer information" (address, name, phone number, etc.) as the output attribute "Search" method with "Number" as input attribute, "Address" and "Name" as output attributes, and "Phone number" in "Pre-master" file as input attribute and "Address" and "Name" as output attribute It can be shown to have a relationship with the "search" method.

The specification database search support unit 12 searches the specification database 3a for an appropriate specification component when accessing the specification database 3 from the user interface unit 10 or reusing the specifications in the specification editor unit 11. The user recognition unit 13 is activated, and the route for searching the specification database 3 created by the search route narrowing unit 14 is presented to the input / output unit 1 via the user interface unit 10.

The user recognition unit 13 performs processing for recognizing the creation status of the system name of the specification currently created by the user and the corresponding function name.

The search route narrowing unit 14 determines the specifications based on the information of the user's creation status recognized by the user recognition unit 13, the creation history of the specifications created in the past, and the related information between the specifications created in the past. A candidate for one or more specification parts to be referred to next is retrieved from the database 3a, or an instruction as to what specification should be prepared next is prepared.

The history creation section 15 stores data of the procedure for creating the specifications created by the user in the creation history database 3b. Creation history is for each application system
If there are specification parts that have been reused and specification parts that have been combined in the order of creation, describe them.

An example of the creation history will be shown below. The number is
Indicates the order of creation. 1. Order entry option 2. Order entry base + order entry option → order entry 3. Order entry → order modification 4. Order entry → Order inquiry In the case of the above example, first create the specification part of "Order entry option", then reuse the result of combining "Order entry base" and "Order entry option" to create "Order entry". Indicates that the "input" has been created. It also shows that "order entry" was reused to create a "order modification" specification part, and then "order entry" was reused to create a "order inquiry" specification part. There is.

The route creation support unit 16 supports the description of effective information when searching the specification database, such as the relationship between existing specification parts or the relationship between created specifications, according to an instruction from the user. It is stored in the database 3c. The contents described in the search path describe the upper / lower relation between specification components and the relation that there is a relation between specification components for each application system.

An example of the search route will be shown below. -Parent link (A, order entry screen transition diagram, advance list inquiry screen) -Parent link (A, order entry screen transition diagram, requester input screen) -Related link (A, order entry time block diagram, order entry screen) Transition diagram) -Related links (A, pre-list inquiry screen, pre-list inquiry screen data / method diagram) In each link, A indicates application A. In the above example, "order input screen transition" Figure "
Has a higher relationship with the "prior list inquiry screen", the "order input screen transition diagram" has a higher relationship with the "request main input screen", and the "order input time block diagram" and the "order input screen transition diagram" It is shown that there is a relation between the “preliminary list inquiry screen” and the “preliminary list inquiry screen data method diagram”.

Here, the specification database 3a is a database for accumulating specifications created in the past. The specification database can be classified and systematized according to the type of specifications. FIG. 5 conceptually shows an example of the specification database 3a (that is, FIG. 5 shows an image of the relationship between specifications by the creator of the specifications). For example, in the field of business processing, the specifications should be divided for each application system, and further divided into specifications that show the division of work according to the flow of time, specifications that show screen transitions, and specifications that show the relationship between screens and files. You can Further, each category can be classified into a basic specification part and an optional specification part.

Further, FIG. 6 shows an example of the structure of the specification database. <> In the figure indicates a directory.
This specification database has a directory for each application. Each directory can have subdirectories (subdirectories are expressed as nested relative to their parent directories). The directory name can be freely decided by the user. The number of directories is also freely available. Each directory can have files and subdirectories. Figure 7
6 shows an example of the internal structure of <specification class 1> which is a subdirectory of <A application system> in the specification database of FIG. This <specification classification 1
> Indicates that the file has files such as a gift system framework, a season closing business framework, and the like, and subdirectories of <basic> and <option>.

FIG. 7 shows the relationship between the above files. This information is described in the search route database 3c for each application. The specification database is assumed to be the same as a general file system, and has various semantic information between specifications.
The framework in which these pieces of semantic information can be described is the search route database 3c, which can be added later to describe the relational data.

FIGS. 8 and 9 show examples of the internal structure of <specification class 2> and <specification class 3>, which are subdirectories of <A application system> in the specification database of FIG. 6, respectively. Show.

The relationship between the basic specification parts, the optional specification parts, and the specifications included in the specification classifications 1 to 3 created using them is described in the creation history.
Further, the upper / lower relations in the specification classification and the relation of the parts relation between the specification classifications are described in the search route (parent link, child link, related link).

An example of description of each specification classification and an example of the relationship between parts are shown in FIGS. 10, 11 and 12.

The creation history database 3b is a database for storing a creation history which is a procedure of specifications created in the past. The creation history database 3b classifies the creation history data for each application.

The search route database 3c is a database that stores the search routes created by the search route narrowing unit 14 and the route creation support unit 16 for searching the specification database. Search route database 3c
Divides the search route data for each application.
For example, the search route of the application system shown in FIG. 5 is, as shown in FIG. 10, FIG. 11 and FIG.
It shows a subordinate relationship and shows a relationship between specifications as described in the description of the search route creation support unit 16. Figure 10
Indicates that the specification describing the “gift system” has specifications of “business during season”, “season closing business”, “season off business”, and “season start business”.
Furthermore, it is shown that the “work during season” has the specifications of “order entry”, “order modification”, and “order inquiry”. These relationships are described using parent links.

FIG. 11 shows "order entry", "order modification",
Indicates that there is a "Order Inquiry" specification part. In addition, "order entry" indicates that it has specifications of "advance list inquiry screen", "requester input screen", and "delivery item input screen". The "preliminary list inquiry screen" indicates that it has a specification of "preliminary list inquiry field move". These relationships are described using parent links.

FIG. 12 shows that there are specification parts of "prior list inquiry screen", "prior master file" and "actual customer master file". Further, the "preliminary list inquiry screen" has specifications of "customer data search" and "customer data display". "Pre-master file" indicates that it has the specifications of "pre-application customer data search" and "pre-application customer data display". The “actual customer master file” has the specifications of “actual customer data search” and “actual customer data display”. These relationships are described using parent links.

On the other hand, "customer data search" is a specification that describes "search", which is the same as "pre-application customer data search" and "actual customer data search". Since they are related, they are described using a related link. Similarly, "Customer data display" is "Pre-application customer data search" and "Actual customer data search".
And the relationship are described using related links.

Further, the specification of "order entry" in FIG. 10 and FIG.
When the specifications of "Order entry" of 1 are related, and Fig. 1
When the specifications of the “preliminary list inquiry screen” of 1 and the specifications of the “preliminary list inquiry screen” of FIG.

Related links (A, (category 1) order entry,
(Category 2) Order entry ・ Related links (A, (Category 2) Pre-list inquiry screen,
(Category 3) Preliminary list inquiry screen) Next, the operation of the software specification reuse support device having such a configuration will be described. 13, FIG. 14 (a),
15 (b), 15 (a), 15 (b), and 15 (c) are flowcharts of the operation of the software specification reuse support apparatus of this embodiment.

First, the user interface unit 1 is activated by the user's instruction from the input / output unit 1 (step P1).

When the user interface unit 1 is started, one of the specification editor unit 11, the specification database search support unit 12, the history creation unit 15, and the route creation support unit 16 is started according to an instruction from the user, or Access the database 3 (steps S1 to S4).

When the specification editor section 11 is activated (step S10), the specification editing screen is activated (step S).
11). According to the user's instruction, the specification editor unit 11 creates specifications as shown in FIGS. 2, 3, and 4 (step S12). The specification component to be reused is loaded from the specification database 3a (steps S13 to S14) and edited according to a user's instruction. When the specification editor unit 11 finishes the creation according to the user's instruction (step S1
5) The history edit screen is activated to support the history creation (steps S16 to S17). When the history is created according to the user's instruction, the route edit screen is activated to assist the route creation (steps S17 to S18). When the creation of the route is completed according to the user's instruction, the user interface unit returns to the activated state (step S19).

When the specification database search support unit 12 is activated (step S20), the user recognition unit 13 is activated to recognize the specification creation status of the user (step S21).
(Process a)). Then, the search route narrowing unit 14 is activated (step S22). When the search route creation unit 14 passes the search route data (steps S23 (process b) and S24), the information is sent to the user interface 1
It is presented to the user through 0 and the user interface is returned to the activated state (step S25 (process e)).

In step S21, the user recognition unit 1
3 is activated, the current specification creation status of the user is recognized and the data is passed to the search route narrowing unit 14. The operation of recognizing the current specification creation status of the user (processing a) is shown in the flowchart of FIG. The latest creation history is recognized from the database (step S210). Present the specification name for the newest specification (step S2)
11). If there is a confirmation input, the process ends (step S).
212). If not, it waits for the input of another specification name (step S213) and waits for the confirmation input again.

In step S23, when the specification creation information of the user is passed to the search route narrowing unit 14, the creation history database 3b and the search route database 3c are searched for the corresponding information by the following procedure, and this user is searched. A suitable database search path is generated and the data is passed to the specification database search support unit 12. The operation (process b) of generating a search route is shown in the flowchart of FIG. A list a of specifications (parts) created according to the specification creation status of the user is created (step S230). A list b of specifications (components) already created is created from the creation history of the referenced specifications (step S231). The elements of the list a are removed from the list b to create a list α of specifications (components) that has not been created (step S232).
The history list β that created the elements of the list α is extracted from the creation history of the referenced specification (step S23).
3). A course γ having the same specification name as the specification being created is extracted from the search path database 3c (step S23).
4). The list α, the list β, and the course γ are passed to the next step as search path data (step S235).

Here, the user's creation status is (category 2).
It is assumed that the "order entry" has just been created. It is assumed that the referred creation history has the following contents.

1. (Category 2) Order entry option 2. (Category 2) Order entry base + (Category 2) order entry option → (Class 2) order entry 3. (Class 2) Order entry → (Class 2) Order modification 4. (Category 2) Order entry → (Category 2) Order inquiry Refer to FIGS.
Suppose In addition, the search route is the above-mentioned parent link,
Suppose it is the content of a related link.

Then, in the flowchart of FIG. 17, .alpha .: [(classification 2) order correction, (classification 2) order inquiry] .beta .: [[[classification 2] order input], [(classification 2) order modification] ], [[(Classification 2) order entry, [(Classification 2) order inquiry]]] γ: Parent link ((Classification 2) order entry, (Classification 2) pre-list inquiry screen) Parent link ((Classification 2) ) Order entry, (Category 2) requester input screen) Parent link ((Category 2) order entry, (Category 2) delivered product entry screen) Related links ((Category 1) order entry, (Category 2) order entry ) Is.

Therefore, the specification database search support unit 12
The information presented to the user in <From the creation history>-"(Classification 2) Order entry can be reused to create (Classification 2) order modification."-"(Classification 2) Order entry By reusing, (Class 2) order inquiry can be created. "<From the search route>-" (Class 2) order entry has (Class 2) advance list inquiry screen as an element. "" (( "Category 2) Order entry has (Category 2) requester input screen as an element."-"(Category 2) Order entry has (Category 2) delivered product input screen as an element."- "(Category 1) order entry and (Category 2) order entry are related."

When the history creation unit 15 is activated (step S30 (process c-1)), the history creation support is performed,
According to a user's instruction, the specification creation procedure of the user is stored in the creation history database 3b (step S31 (process c
-2)). When the editing is completed according to the user's instruction, the user interface unit returns to the activated state (step S3).
2).

When the route creation support unit 16 is activated (step S40 (process d-1)), the route creation support is performed,
According to a user's instruction, the know-how of the relationship between specifications and the range of specifications to be referred to is stored in the search path database 3c (step S41 (process d-2)). When the editing is completed according to the user's instruction, the user interface unit returns to the activated state (step S42).

When the user selects access to the specification database 3 (steps S4 and S50), the specification D
B, reference, load, correction, new file creation, etc. are supported (steps S51, S52). When the access is completed according to the user's instruction, the user interface unit returns to the activated state (step S53).

The user interface section is ended by the user's instruction from the input / output section 1 (steps S4, S).
50, S54).

In step S20, the specification database search support unit 12 is activated, and when the search route data is obtained as described above, the information is presented to the user through the user interface 10 in step S25. , Interaction with the user is performed. The presentation of the search route data to the user (process e) is shown in the flowchart of FIG.

First, as a search route menu, (reference system) history (currently usable) specification part candidates related specification parts and upper specification parts are presented (step S250).

When the history () is selected, it is presented (step S2511).

If the candidate of specification parts () is selected,
This is presented (step S2521).

When the related specification part () is selected, the specification name linked by the related link is extracted from the course γ (step S2530). The related specification name is presented (step S2531). When it is desired to extend the link search and a specification is input, a course is extracted (step S2533), and the same processing is performed from step S2530.

When the upper specification part () is selected,
A specification name linked by a parent link is extracted from the course γ (step S2540). The upper specification name is presented (step S2541). If you want to extend the link search,
When the specification is input, the course is extracted (step S2543), and the same processing is performed from step S2530.

As described above, according to the software specification reuse support apparatus of the present embodiment, the software specification, the creation history of the software specification, and the related information between the software specifications are stored in the database. The relationships in the specification database are clarified, and next candidates for specifications that can be reused can be provided, and the next creation procedure can be guided, so that productivity of specification creation is improved. In addition, since the relationship between specifications is shown by the guide, the range of influence of the correction content is clarified, and the reliability of specification creation is improved.

(Second Embodiment) Next, a second embodiment of the present invention will be described.

The present embodiment is a functional expansion of the first embodiment. That is, first, in the present embodiment, the description of the search route database in the first embodiment is expanded so that the link attribute, which is information indicating what kind of relationship between specifications exists, can be arbitrarily set. At the same time, those having the same link attribute and related to each other can be described as a relationship between a plurality of specifications. In this embodiment, this is called a link database.

Further, in the present embodiment, the function of presenting information to the user by the specification database search support unit in the first embodiment is further expanded so that the user can freely specify the type of link attribute together with the priority. Along with this, guide information is generated to support the reuse of the existing specifications. In this embodiment, it is called a specification database reuse support unit.

Further, in the present embodiment, a working memory having three slots for storing the specification creation status at any time is provided, and in the first embodiment, the history creation unit which is supposed to be manually operated is automatically operated. The creation history can be created and registered in. In this embodiment, it is called a creation history generation unit.

In the present embodiment, the specification includes the same concept as in the first embodiment, but the way of expressing the relationship between the specifications is expanded by the link database, so that the specification can be handled accordingly. The structure of the specification can also be expanded.

FIG. 19 is a block diagram of the software specification reuse support apparatus according to this embodiment. As shown in the figure,
The software specification reuse support apparatus according to the present exemplary embodiment includes an input / output unit 101, a processing unit 102, and a database 103. The processing unit 102 advances the processing while accessing the database 103 by an instruction / data input from the input / output unit 101. The arrows in FIG. 19 indicate the flow of data and control signals.

The input / output unit 101 is composed of a keyboard which is an input device, a CRT which is an output device, and the like, and can input and display software specifications. A so-called mouse can be used or used as the input device. As the output device, a printer can be used or used in combination.

The processing section 102 includes a user interface section 110, a working memory section 120, and a specification editor section 1.
30, a specification database reuse support unit 140, and a reuse know-how acquisition unit 150. The processing unit 102 is configured by using, for example, a CPU and a memory, and functions are provided by software processing.

The database 103 comprises a specification database 160 and a reuse know-how database 170.

The reuse know-how database 170 comprises a creation history database 171 and an inter-specification relationship knowledge database 172. Further, the inter-specification relationship knowledge database 172 includes a link database 173 and a link attribute database 174. As will be described later in detail, the specification database 160 is a database for accumulating specifications created in the past, and the creation history database 171.
Is a database that stores a creation history that is a procedure of specifications created in the past. The link database 173 is a database that describes the relationship between the specifications of the specification component, and the link attribute database 174 is a database that describes the type of attribute in the relationship between the specifications described in the link database 173.

The user interface section 110 accesses the specification database 160 and inputs the contents into the input / output section 101.
Display to. Further, the specification editor unit 130, the specification database reuse support unit 140, the reuse know-how acquisition unit 15
Input / output unit 10 for starting, ending, and executing contents for each 0
Display to 1.

The specification editor section 130 calls an editor necessary for creating specifications, such as a text editor or a graphic creation editor, and supports the description of specifications forming software. Further, the files accumulated in the specification database 160 can be read / edited / saved.

The working memory unit 120 records operations such as reading, synthesizing, and saving of specification files performed by the user through the specification editor unit 130. The working memory unit 120 includes a WM1 slot that describes an application name that indicates the entire system that is being created, a WM2 slot that describes a list of specification names that have already been created among the applications described in the WM1 slot, and a specification. It consists of a WM3 slot that temporarily stores the work process of creation.

The specification database reuse support unit 140
User recognition unit 141, reuse know-how type selection unit 14
2, reuse guide generation unit 143, reuse guide presentation unit 1
44, and generates and presents a guide for selecting a specification to be reused to the user.

The user recognizing unit 141 recognizes the creation status of the system name of the specification currently created by the user and the corresponding function name.

The reuse know-how type selection unit 142 presents to the user the types of reuse know-how described in the link attribute database 174, and supports the input of the types of know-how and their priorities suitable for the purpose of reuse. Then, the input data is passed to the reuse guide generation unit 143.

The reuse guide creating unit 143 uses the reuse know-how database based on the user creation status obtained by the user recognizing unit 141, the kind of know-how passed from the reuse know-how type selecting unit 142, and their priorities. An appropriate know-how is selected from the know-how such as the creation history described in 170 and the related knowledge between specifications, and one or more specification parts candidates to be reused by the user are given,
Or create a guide consisting of presentations such as what specifications should be created next.

The reuse guide presenting unit 144 presents or outputs the guide created by the reuse guide creating unit 143 to the user through the user interface.

The reuse know-how acquisition unit 150 is composed of a creation history generation unit 151, a know-how type selection unit 152, and a know-how data creation unit 153, and assists the user in registering the know-how obtained by the reuse. To do.

The creation history generating unit 151 has the contents of "save" in the WM3 slot of the working memory unit 120.
Each time it is performed, the work process up to that point is accumulated in the creation history database 171.

For example, when the A file is read, the B file is synthesized, and the file is stored in the C file, the history when written in the working memory is A file + B file → C file. When the history storage is completed once, the contents of WM3 in the working memory are reset.

The know-how type selection unit 152 is used when the user wants to accumulate or modify the reuse know-how.
The link attribute database 174 is instructed by the user.
The type of know-how described in (1) is presented, and the type name of the selected know-how or the type name of the new know-how is passed to the know-how data creation unit 153.

The know-how data creating section 153 presents the know-how type name or the new know-how type name sent from the know-how type selecting section 152 to the user. Next, the know-how information input by the user is stored in the link database 17
Add / edit / delete to 3.

The specification database 160 is a database for accumulating specifications created in the past. The specification database 160 can be classified and organized according to the type of specifications.

The reuse know-how database 170 is composed of a creation history database 171 and an inter-specification relationship knowledge database 172.

The creation history database 171 is a database that stores a creation history that is a procedure for creating specifications created in the past. An example of the creation history is shown below. The numbers represent the order of creation.

1. → Order entry option (A system, screen transition diagram) 2. Order entry basic (A system, screen transition diagram) + order entry option (A system, screen transition diagram) → order entry actual work (A system, screen transition diagram) 3. Order entry actual work (A system, screen transition diagram) → Order correction actual work (A system, screen transition diagram) 4. Order input actual work (A system, screen transition diagram) → Order inquiry actual work (A system, screen transition diagram) This example shows a procedure for creating specifications of the “gift system” of a department store A. The "gift system" is
Even if department stores are different, they have the task of "order entry", which writes order details in a file. The “order entry input option (A system, screen transition diagram)” indicates a sub-portion in the screen transition diagram of the order entry business of the department store A, which is different for each department store.

[0107] "Order entry basic (A system, screen transition diagram)" represents a screen transition diagram of common business among order entry inputs even if department stores are different.

The "order entry actual work (A system, screen transition diagram)" represents the entire screen transition diagram of the order entry work of a department store A.

Similarly, the "order correction actual work (A system,
"Screen transition diagram)" and "order inquiry actual work (A system, screen transition diagram)" respectively represent the entire screen transition diagram of the order correction work and order introduction work of a certain department store A.

The above creation history indicates the following. First, create a screen transition diagram for "Order entry option (A system, screen transition diagram)". Next, the result of combining "Order entry basic (A system, screen transition diagram)" and "Order entry option (A system, screen transition diagram)" is reused, and "Order entry actual work (A system, screen transition)" is reused. Transition diagram) ”is created. Next, reuse the "order input actual work (A system, screen transition diagram)" to create a "order correction actual work (A system, screen transition diagram)" screen transition diagram, and then " It shows that the screen transition diagram of "order inquiry actual work (A system, screen transition diagram)" is created by reusing "order input actual work (A system, screen transition diagram)".

Here, the screen transition diagram is given as an example of the specification, but as described above, the specification may be any data that can identify the file name and the like.

The inter-specification relationship knowledge database 172 includes a link database 173 and a link attribute database 1.
It is composed of 74.

The link database 173 describes the relationship between specifications of specification parts. Link database 1
The format of 73 is as follows. [[Specification 1, Specification 2, Specification 3, ...], [Specification a, Specification b, Specification c, ...], [Attribute α, Attribute β, Attribute γ, ...]] , 3 have a relationship of specification α, specification b, specification c, ... And attribute α, attribute β, attribute γ ,.

The following is a description example of the link database 173. a) [[Order entry actual work (A system, screen transition diagram)], [Advance list inquiry screen (A system, screen layout), Requester input screen (A system, screen layout)], [Parent and child]] b ) [[Order entry actual work (A system, screen transition diagram)], [Advance list form (A system, screen layout), Order list form (A system, screen layout)], [Related]] Input work division diagram (A system, work division diagram)], [Order entry actual work (A system, screen transition diagram)], [Modification impact, term (order entry)]] The screen transition diagram of "order input actual work" shows that it has a parent-child relationship with the screen layouts of the "advance list inquiry screen" and the "requester input screen" of the A system.

In the above example b, it is shown that the screen transition diagram of "order input actual work" of the A system is related to the screen layouts of "advance list form" and "order list form" of the A system. . The term “association” here means that there is no special attribute and that only a relationship is established.

[0116] In the above example c, "order entry input work division diagram"
This business division diagram is the "order input actual business" of system A
The screen transition diagram shows that modifying one of them has the effect, and that the term "order entry" is common.

The link attribute database 174 describes the types of attributes in the relation between specifications described in the link database 173.

The following are examples of the types of attributes. -Creation history-Correction effect-Relationship-Terms-Parent-child The above "relationship" is subdivided into the degree of relationship, such as "relationship (large)", "relationship (middle)", "relationship (small)", Attributes may be provided. In addition to the above, various types of attributes can be arbitrarily designated.

Next, the operation of the software specification reuse support device having such a configuration will be described. 20 to 2
FIG. 3 shows a flowchart of the operation of the software specification reuse support device of this embodiment.

First, the user interface unit 110 is activated by the user's instruction from the input / output unit 101 (step P101).

When the user interface unit 110 is activated, the specification editor unit 13 is instructed by the user.
0, the specification database reuse support unit 140, or the reuse know-how acquisition unit 150 is activated (step S1).
01-S103).

When the specification editor section 130 is activated (step S110), the working memory section 120 is activated (step S111), and the user inputs the name (application name) of the entire system for creating specifications.
Described in the WM1 slot (step S112). Then, the specification edit screen is activated (step S11).
3). According to the user's instruction, the specification editor unit 130 creates desired specifications (step S114). Further, a file of the specification part to be reused is loaded from the specification database 160, edited / composed according to a user's instruction, and saved (steps S115, S11).
6, S118). In the WM2 slot of the working memory unit 120, the name list of the created specification file is described (step S119), and in the WM3 slot, among the contents of the work executed by the specification editor unit 130, loading / compositing / saving of files is performed. Recorded (step S11)
7).

When "save file" is described in the working memory unit 120 (step S1)
19), the creation history generation unit 151 of the reuse know-how acquisition unit 150 is activated (step S120), and the work process in the working memory is described as a creation history in the creation history database 171 (step S121 (process s)). . When the specification creation state is returned after the description is completed,
When proceeding to step S114 and ending the specification editor unit 130, the process returns to step P101 and (step S12
2).

Here, an example of the operation (process s) from generation of creation history to registration in step S121 is shown in the flowchart of FIG. First, WM3 of working memory
(Work process) is read (step S500). When reading from the first line line by line (step S501) and "Read XX file" is described (step S5)
02), and converts it into a "XX file" (step S50).
5), if it is described as "○○ file composition" (step S503), it is converted to "+ ○○ file" (step S506), and if it is described as "save file" (step S504) , "→ ○ file" (step S507). However, the above ○○ is
Represents a file name. And if WM3 is not empty,
The processes after step S501 are repeated (step S5
08), if the line is blank (step S508), the conversion result is described in the creation history database 171 (step S5).
09).

On the other hand, the specification database reuse support unit 14
When 0 is activated (step S130), the user recognition unit 1
41 is activated (step S131), the specification creation status of the user is recognized (step S132 (process t)), and the result is passed to the reuse guide generation unit 143.

Subsequently, the reuse know-how type selection unit 142
Is activated (step S133), the user is allowed to determine the type of know-how to be reused and the priority of the know-how, and the result is passed to the reuse guide generation unit 143. Note that the type of know-how to be reused and the priority of the know-how may be set in advance so that this step can be omitted.

The user's creation status, the type and priority of the know-how to be reused are passed to the reuse guide generator 143, and when activated (step S134), the creation history database 171 of the reuse know-how database 170 is created. The database reuse guide information suitable for this user is generated from the link database 173 (step S1).
35 (processing u)), the reuse guide presenting unit 1
Hand over to 44.

Next, the guide generated by the reuse guide presenting unit 144 is transferred to the user interface unit 11.
It is presented to the user through 0 (step S136) and returns to the activated state of the user interface (step P10).
1).

Here, an example of the operation (process t) of recognizing the current specification creation status of the user in step S132 is shown in FIG.
It is shown in the flowchart. First, W of working memory
M3 (work process) is read (step S301). Read line by line from the first line (step S302), and
If "○ file read" is described (step S303), the "XX file" is presented to the user as the name of the specification currently being created (step S304). If there is a confirmation input (step S305), the process ends.
If not (step S305), input of another specification name is waited (step S306), and confirmation input is waited again (step S305).

Next, an example of the guide generation operation (processing u) in step S135 is shown in the flowcharts of FIGS. First, WM2 (list of specifications already created) in the working memory is read (step S40).
0). The specification name (of the specification being created) obtained in the process t is recognized (step S401). The creation history database 171 is read (step S402).

Then, each history is read (step S
403), if at least one element on the left side is an element of WM2 and all the elements on the right side are not included in WM2 (steps S404, S405), the corresponding expression is temporarily stored in a file. Add to α (step S4)
06). The processes of steps S403 to S406 are repeated until the history reading is completed (step S
407).

Next, the history of the file α is read one by one (step S408), and if there is an element on the left side that is not included in WM2, this is set as element e (step S409), and the created history database 171 is saved. Each history is searched (step S410), and when the element e is on the right side (step S411), the corresponding expression is temporarily added to the file β (step S412). The processes of steps S408 to S412 are repeated until the history search is completed (step S413), and then the files α and β are combined and sorted in the order described, and this is set as the file γ (step S414).

Next, the specification name of the specification currently being created obtained in the process t is recognized, and this is substituted for "SPEC" (step S415). The link database 173 is read (step S416). Link database 1
The know-how of 73 is read one by one (step S41
7) If the same name as the specification name indicated by “SPEC” appears in the know-how (step S418), the relevant know-how formula is temporarily added to the file θ (step S418).
419), the type and order of the attribute of the know-how designated by the user is read (step S420), and the know-how of the file θ is read one by one (step S421). The processes of steps S417 to S421 are repeated while the know-how of the attribute designated by the user is set (step S42).
2) Then, the relevant know-how formula is added to the file λ (step S423).

Next, the know-how attributes designated by the user (arranged in order of priority) are read one by one (step S424). If the attribute is "creation history" (step S425), the file .gamma. Is added (step S426).

When the reading of the attributes is completed (step S427), the contents of the file μ are used as a guide (step S433), and the temporarily created files α, β, γ,
After deleting θ, λ, and μ, the process ends (step S43).
4).

If the reading of the attributes is not completed (step S427), the know-how of the corresponding attribute is read from the first case of the file λ (step S428). If the file λ becomes empty, the contents of the file μ are read. As a guide (step S433), the temporarily created file α,
After deleting β, γ, θ, λ, and μ, the process ends (step S434). On the other hand, if it is not empty (step S
429), add to the file μ (step S430),
The know-how currently read is deleted from the file λ (step S431), and if the check is not completed up to the last line of the file λ (step S432), step 4
Returning to step 28, when the check is completed up to the last line of the file λ (step S432), the procedure returns to step 424.

When the reuse know-how acquisition unit 150 is activated (step S140), the know-how type selection unit 1
52 is activated (step S141), the contents described in the link attribute database 174 are read and presented through the user interface. The type of know-how is selected or the type of new know-how is registered according to a user's instruction (step S142). The type of new know-how is described in the link attribute database.

When the user designates the type of know-how or the type name of new know-how by the know-how type selection unit 152, the know-how data creation unit 153 is activated (step S143).

Next, the user writes the know-how of the specified kind of know-how using the editor (step S14).
4), the creation history database 171 or the link database 173 is described (step S145). Alternatively, the know-how described in the past is called from the creation history database 171 or the link database 173,
Edit / delete with editor (step S14)
4, S145).

When the editing is completed by the user's instruction (step S146), the user interface section 110 is returned to the activated state (step P101).

It should be noted that the user interface unit 110 is terminated by the user's instruction from the input / output unit 101 (step S104).

Next, a specific example of the process for generating the above guide will be shown.

Here, it is assumed that the creation status of the user has just completed the creation of an order entry actual job, which is a screen transition diagram of a certain B system. For the B system,
It is assumed that a screen transition diagram for the order entry option and order entry basic has already been created. As a target for reuse, the specifications and reuse know-how of the A system that has already been created are used. The creation history, the link database, and the link attribute database, which are the know-how for reusing the A system, have the following contents.

<Example of Creation History> 1. → Order entry option (A system, screen transition diagram) 2. Order entry basic (A system, screen transition diagram) + order entry option (A system, screen transition diagram) → order entry actual work (A system, screen transition diagram) 3. Order entry actual work (A system, screen transition diagram) → Order correction actual work (A system, screen transition diagram) 4. Order input actual work (A system, screen transition diagram) → Order inquiry actual work (A system, screen transition diagram) 5. → Actual result input option (A system, screen transition diagram) 6. Actual order input business (A system, screen transition diagram) + actual result input option (A system, screen transition diagram) → Actual input business (A system, screen transition diagram) <Example of link database> a) [[Order input actual Work (A system, screen transition diagram)], [Preliminary list inquiry screen (A system, screen layout), main request input screen (A system, screen layout)], [parent and child]] b) [[Order entry actual work (A system, screen transition diagram)], [Advance list form (A system, screen layout), Order list form (A system, screen layout)], [Related] c) [[Order entry work division diagram (A system) , Business division diagram)], [Order entry actual work (A system, screen transition diagram)], [Correction impact, term (order entry input)] <Example of link attribute database> Creation history Modification impact Related terms Parent and child It is assumed that the user has set the type of know-how and the priority as follows when selecting the kind of know-how.

<Setting Example 1> Priority 1: Creation history Priority 2: Effect of modification Priority 3: Related Priority 4: Term Priority 5: Parent / Child <Setting Example 2> Priority 1: Related Priority 2: Term Priority 3: Effect of correction Priority 4: Creation history Here, the procedure shown in the flowcharts of FIGS. 25 to 28 is executed, and the following steps i, ii, and iii are executed.

I) WM2 = recognition of a list of specifications that have already been created ii) recognition of a specification name that is currently being created or immediately after completion of the contents of WM3 iii) Even if there is one element on the left side of the creation history Those that are included in WM2 and whose right-hand side elements are not included in WM2 (that is, an expression showing the procedure for creating an uncreated specification using an already-created specification) and the left-hand side element of the above expression, Elements that are not included in the WM2 are included in the right side (that is, an expression indicating a procedure for creating an element that satisfies the combination in the above expression), and the elements are sorted in the described order.

As a result, the extracted and sorted creation history is as follows. <Creation history> 1. Order input actual work (A system, screen transition diagram) → Order correction actual work (A system, screen transition diagram) 2. Order input actual work (A system, screen transition diagram) → Order inquiry actual work (A system, screen transition diagram) 3. → Actual result input option (A system, screen transition diagram) 4. Order input actual work (A system, screen transition diagram) + actual result input option (A system, screen transition diagram) → actual result input actual work (A system, screen transition diagram) Therefore, the guide generated by the reuse guide generation unit 143 For example, the following is generated and output.

<Guide Corresponding to Setting Example 1> 1. The order input actual job which is the screen transition diagram of the A system is reused to create the order correction actual job which is the screen transition diagram of the A system. 2. The order input actual job which is the screen transition diagram of the A system is reused to create the order inquiry actual job which is the screen transition diagram of the A system. 3. An order entry option, which is a screen transition diagram of the A system, is created. 4. A is a screen transition diagram of the system A, which is an actual order input operation and A
Create a performance input actual job that is a screen transition diagram of the system. 5. There is a relationship between the order input work division chart, which is the division chart of the A system, and the effect of modification. 6. It is related to the pre-list form, which is the form layout of the A system, and the ordered list form (A system, form layout). 7. Order entry input, which is a business division diagram of the A system, and the term "order entry" are related. 8. There is a parent-child relationship with the prior list inquiry screen, which is the form layout of the A system, and the requester input screen.

Messages 1 to 4 in this guide correspond to the designation of the creation history, message 5 corresponds to the correction effect,
Message 6 corresponds to association, message 7 corresponds to term, message 7 corresponds to parent and child.

Further, in the above example, the respective messages corresponding to the specified types of attributes are output in the order of the set priority.

<Guide Corresponding to Setting Example 2> 1. It is related to the pre-list form, which is the form layout of the A system, and the ordered list form (A system, form layout). 2. Order entry input, which is a business division diagram of the A system, and the term "order entry" are related. 3. There is a relationship between the order input work division chart, which is the division chart of the A system, and the effect of modification. 4. The order input actual job which is the screen transition diagram of the A system is reused to create the order correction actual job which is the screen transition diagram of the A system. 5. The order input actual job which is the screen transition diagram of the A system is reused to create the order inquiry actual job which is the screen transition diagram of the A system. 6. An order entry option, which is a screen transition diagram of the A system, is created. 7. A is a screen transition diagram of the system A, which is an actual order input operation and A
Create a performance input actual job that is a screen transition diagram of the system.

Message 1 in this guide corresponds to the designation of association, message 2 corresponds to the term, message 3
Corresponds to the correction effect, and messages 4 to 7 correspond to the creation history. Here, since the parent and child are not designated, the message corresponding to the message 8 in the guide corresponding to the setting example 1 is not output.

Note that only candidates to be reused may be presented as a guide corresponding to the designation of the creation history.

Further, as a guide corresponding to the designation of the creation history, only a plurality of candidates to be reused are presented, the candidate designation input by the user is waited, and only the designated candidate is presented with the usage method. Is also good.

Other various guide generation / presentation methods can be implemented.

As described above, according to the software specification reuse support apparatus of the present embodiment, know-how such as past specification creation history and information about the relationship between specification parts is accumulated, so that the specification database is stored. As the relationship becomes clear, the scope of effect of the correction becomes clear. Then, in the specification creation process in software development, the user recognizes the user's specification creation status and considers the user's purpose of reuse, and re-creates it from know-how such as past specification creation history and information on the relationship between specification parts. Produce a guide for appropriate specification reuse, such as available specifications and creation procedures, or information about the relationship between specifications, and present it to the user to specify the specifications and specification parts to be reused or changed. Can assist in the decision. Further, it is possible to support the work of accumulating in the database the know-how such as the creation procedure when reusing the specifications and the related knowledge between the specifications, and freely adding / correcting.

Therefore, it is possible to effectively use the specifications, and it is possible to improve the productivity in the software specification creation work and the reliability of the completed specifications. (Modification) By the way, in the first embodiment, the history creation unit is described on the premise of the manual mode, but it may be in the automatic mode as in the second embodiment. Further, the automatic mode and the manual mode may be switched to be used.

In the second embodiment, the description is made on the assumption that the creation history generating section is in the automatic mode, but it may be in the manual mode as in the first embodiment. Further, the automatic mode and the manual mode may be switched to be used.

The present invention is not limited to the above-described embodiments, but can be implemented with various modifications without departing from the scope of the invention.

[0160]

According to the present invention, a mechanism is provided for accumulating information indicating the history of creation of specifications that have already been created and the relationship between specification parts. Since it is possible to support the reuse of specifications, in the specification creation process in software development,
The specifications can be effectively used, and productivity can be improved and the reliability of the completed specifications can be improved.

According to the present invention, the creation history of specifications and the information on the relationship between specification parts are accumulated in the database,
Since it is possible to support the work of adding and modifying freely, it is possible to make more effective use of specifications in the process of creating specifications in software development, aiming to improve productivity and further improve the reliability of completed specifications. You can

[Brief description of drawings]

FIG. 1 is a block diagram showing the configuration of a software specification reuse support device according to a first embodiment of the present invention.

FIG. 2 is a diagram showing an example of a description of specifications that can be described by a specification editor unit in FIG.

FIG. 3 is a diagram showing another example of description of specifications that can be described by the specification editor unit of FIG.

FIG. 4 is a diagram showing still another example of description of specifications that can be described by the specification editor unit of FIG.

FIG. 5 is a conceptual diagram showing an example of the configuration in the specification database.

FIG. 6 is a diagram showing an example of the structure of a specification database.

7 is a diagram showing the internal structure of the specification database of FIG.

8 is a diagram showing the internal structure of the specification database of FIG.

9 is a diagram showing the internal structure of the specification database of FIG.

FIG. 10 is a diagram showing an example of a classification of specifications that constitute a specification database.

FIG. 11 is a diagram showing an example of classification of specifications constituting a specification database.

FIG. 12 is a diagram showing an example of classification of specifications that constitute a specification database.

FIG. 13 is a flowchart showing the operation of the software specification reuse support device according to the embodiment.

FIG. 14 is a flowchart showing the operation of the software specification reuse support device according to the embodiment.

FIG. 15 is a flowchart showing the operation of the software specification reuse support device according to the embodiment.

FIG. 16 is a flowchart showing a procedure for recognizing a specification creation status of a user.

FIG. 17 is a flowchart showing a procedure for generating search route data.

FIG. 18 is a flowchart showing the procedure of the interaction between the user and the system after presenting the search route information to the user.

FIG. 19 is a block diagram showing a configuration of a software specification reuse support device according to a second embodiment of the present invention.

FIG. 20 is a flowchart showing the operation of the software specification reuse support device according to the embodiment.

FIG. 21 is a flowchart showing the operation of the software specification reuse support device according to the embodiment.

FIG. 22 is a flowchart showing the operation of the software specification reuse support device according to the embodiment.

FIG. 23 is a flowchart showing the operation of the software specification reuse support device according to the embodiment.

FIG. 24 is a flowchart showing a procedure for creating and registering a creation history.

FIG. 25 is a flowchart showing a procedure for recognizing a specification creation status of a user.

FIG. 26 is a flowchart showing a procedure for generating a reuse guide.

FIG. 27 is a flowchart showing a procedure for generating a reuse guide.

FIG. 28 is a flowchart showing a procedure for generating a reuse guide.

FIG. 29 is a flowchart showing a procedure for generating a reuse guide.

[Explanation of symbols]

1 ... Input / output unit, 2 ... Processing unit, 10 ... User interface unit, 11 ... Specification editor unit, 12 ... Specification database search support unit, 13 ... User recognition unit, 14 ... Search route narrowing unit, 15 ... History creation unit , 16 ... Route creation support unit,
3 ... Database, 3a ... Specification database, 3b ... Creation history database, 3c ... Search route database, 1
01 ... I / O unit, 102 ... Processing unit, 103 ... Database, 110 ... User interface unit, 120 ... Working memory unit, 130 ... Specification editor unit, 140 ... Specification database reuse support unit, 150 ... Reuse know-how acquisition unit, 141 ... User recognition unit, 142 ... Reuse know-how type selection unit, 143 ... Reuse guide generation unit, 144 ... Reuse guide presentation unit, 151 ... Creation history generation unit, 152 ...
Know-how type selection unit, 153 ... Know-how data creation unit,
160 ... Specification database, 170 ... Reuse know-how database, 171 ... Creation history database, 172 ...
Knowledge database between specifications, 173 ... Link database, 174 ... Link attribute database

─────────────────────────────────────────────────── ─── Continuation of the front page (51) Int.Cl. ⁶ Identification code Internal reference number FI technical display location 9191-5H G06F 15/60 604 G

Claims (16)

[Claims] 1. A database storing previously created software specifications, a history of creating the software specifications, and related information between the software specifications, and a new software specification using the software specifications stored in the database. A specification creating means for creating, a recognition means for recognizing a current specification creating situation by the specification creating means, and a history creating means for accumulating a procedure of the specification creating performed by the specification creating means in the database as an creating history. And a route creating means for accumulating a route for searching the database in the database as related information, from the specification creation status, the creation history, and the related information,
A search route narrowing means for narrowing down the route for searching the software specifications stored in the database; and a specification database searching means for searching the software specifications stored in the database based on the route narrowed down by the search route narrowing means. A software reuse support device having. 2. The software reuse support apparatus according to claim 1, further comprising a presenting means for presenting reusable software specification candidates based on a search result of the specification database searching means. 3. The software reuse support apparatus according to claim 2, wherein the presenting means presents an editing procedure for the presented reusable software specification candidates. 4. A software specification created in the past, a creation history of the software specification created in the past, and related information between the software specifications created in the past are input from the outside, and a new software specification is created using this information. Is a software reuse support device for inputting an already-created software specification from the outside and using it to create a new software specification and the creation status by this editing means. Based on the recognition means, the creation status, and the creation history and the related information related to the software specifications input from the outside, candidates for reusable software specifications are selected from among the software specifications stored in the specification database. Software reuse support characterized by having presentation means for presenting Location. 5. The software reuse support apparatus according to claim 4, wherein the presenting means presents an editing procedure for the presented reusable software specification candidates. 6. The creation history includes information describing a software specification name and a creation order of the software specification,
6. The software reuse support apparatus according to claim 1, wherein the software reuse support apparatus further includes information describing a usage relationship between other software specifications as needed. 7. The related information according to claim 1, wherein the related information includes information describing two or more software specifications, the names of those software specifications and how they are related to each other. The software reuse support device described. 8. A database storing accumulated software specifications created in the past, history of creation of the software specifications, and link information indicating types of relationships between the software specifications, and software specifications accumulated in the database. Specification creation means for creating a new software specification, recognition means for recognizing the current specification creation status by the specification creation means, and a procedure for the specification creation performed by the specification creation means in the database as a creation history. A history creating means for storing, a software specification created by the specification creating means, and a link information creating means for storing in the database the type of association between the software specifications stored in the database as link information, Specification creation status, creation history, link information, and A software reuse support apparatus comprising: a reuse guide generation unit that generates guide information for reusing the software specifications stored in the database, based on the determined relation type and its priority. . 9. The software reuse support apparatus according to claim 8, wherein the type of the association can be arbitrarily designated by one type or a plurality of types from the outside. 10. The relation type is a creation history indicating that one software specification can be used to create the other software specification, and modification of one software specification affects the other software specification. The impact of modification indicating that there is a relationship
Among the terms parent-child indicating that there is a subordinate relationship, relation indicating that there is a relationship other than upper and lower relations between software specifications, and the relationship indicating that a common term is used in both software specifications The software reuse support device according to claim 9, wherein the software reuse support device includes at least one. 11. The reusable guide creating means, when the designated association type includes a creation history, creates a reusable software specification candidate as the guide information. The software reuse support device described. 12. The reuse guide generation means, when the designated association type includes a creation history, generates a reusable software specification candidate and an editing procedure using the candidate as the guide information. The software reuse support device according to claim 10. 13. The reuse guide generation means, when a plurality of types of relations are designated, outputs the guides generated corresponding to the respective types of relations in the order of designated priorities. The software reuse support device according to claim 8. 14. The creation history includes information describing a software specification name and a creation order of the software specification, and, if necessary, information describing a usage relationship between other software specifications. The software reuse support apparatus according to any one of claims 8 to 13. 15. The link information according to claim 8, wherein the link information includes information describing two or more software specifications together with their software specification names and how they are related. The software reuse support device described. 16. The software reuse support apparatus according to claim 8, further comprising means for editing the creation history and the link information accumulated in the database.