JPH11184687A - Software document creation system using hierarchical structure and relation of software document and its operation method - Google Patents

Abstract

(57) [Summary] [PROBLEMS] A software document creation system using a hierarchical structure and relationships of software documents capable of easily creating various documents, which are products generated in a software development process, and maintaining and managing these documents with consistency. Provide the operation method. SOLUTION: The association between document contents is described by a chapter and a section of the document.
Equipped with a device that can create a document while easily defining the sections and paragraphs, the relations between paragraphs, etc. in a hierarchical manner, and automatically generating such associations in the upper hierarchy by changing the associations in the lower hierarchy. In addition, a relationship management device is provided which can maintain the same even when it is changed or deleted. A template created in advance is provided so that it is not necessary to create such documents one by one from the beginning, so that the document can be easily created while correcting the document.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software document creating system using a hierarchical structure and relation of software documents and an operating method thereof, and more particularly, to creating, storing, and retrieving a document generated in a software development project, the hierarchical structure of the document. , And expresses and manages the dependencies (or relevance) between hierarchies so that documents can be created easily, and the hierarchical structure and relationships of software documents that can be maintained and maintained with consistency between documents The present invention relates to a software document creation system and a technology for operating the software document.

[0002]

2. Description of the Related Art Generally, in a software development process, there are various types of documents that are created for development and management purposes, or that are indispensable for contract purposes. For example, it is a document such as a proposal, a contract, a requirement definition, an analysis specification, a design specification, a test plan, and a test result. Creating and managing these various types of software documentation requires considerable experience and effort. In particular, such software documents are often content related. For example, the performance requirements of the requirement definition document are connected to a specific device at the time of design, and are embodied by the specific device and a program in the realization process. In the test process, a test plan and a test result report for testing the device and the program are required. Such relevance may arise when modifying, changing, maintaining, or repairing the software.
This causes many difficulties in maintaining consistency between documents.

[0003] When the contents of a document are changed,
Tracking and changing related documents can maintain consistency between documents, but it is difficult to create and change documents while maintaining such consistency in most software development processes. It is in. For this purpose, tools for supporting documentation are required. Looking at the conventional software documentation management device in this regard, the developed countries, especially the United States, already have CASE (Computer Aided
Software Engineering) Many software development support tools, mainly tools, have been developed, and products based on this development are in stable use.

[0004] However, such a support tool is a support tool for supporting the construction of an application program and a database, and has a form of supporting a documentation function. Therefore, a satisfactory level of documentation is provided. It is not a support tool. In other words, since the contents are grasped based on the contents analyzed, designed, and programmed, and technical documents for subsequent maintenance and repair are generated, various kinds of products as actual products in the development process are created. There is a problem that it is not a documentation support tool to help create documents (specifications, plans, result report format, etc.).

In particular, since most support tools are dependent on a specific software development methodology, projects using different development methodologies have the inconvenience of using the appropriate support tools, and the dependency between documents is reduced. The ability to express and manage to help create consistent documents is even weaker. Also, the consistency maintenance technique used in existing documentation support tools generally considers a document as a set of several related modules, and connects links in units of one module that constitutes the document. By indicating the dependency between modules, a module referred to when creating or modifying documents can be displayed and searched. Therefore, the life cycle or the position of the document within the project is not taken into account and the hierarchical characteristics of the document are not reflected. In addition, in the case of a module having an indirect relationship, when deleting a module, the link between the two modules is ignored and the module becomes completely unrelated.

[0006]

SUMMARY OF THE INVENTION Accordingly, the present invention has been conceived in order to solve the problems of such existing documentation support tools.
All industrial entities (system integrators, software houses, in-house developers) who develop software while establishing a hierarchical structure and relationships that are independent of development methods and procedures and can maintain consistency are software development processes The purpose of the present invention is to provide a software document creation system using a hierarchical structure and relationships of software documents that can easily create, maintain, and manage the various documents that are the products generated by the above, and provide a method of operating the same. I have.

[0007]

The structure and operation of the present invention for achieving the above object will be described in detail as follows. The structure of the present invention is a life cycle manager (Lifecycle Manager) that can define the stage of the project and the software life cycle and the generated document for each stage, and the relationship between the documents, the individual structure of the document is set, and the A relationship manager (Link Manager) for setting relationships, a content module editor (Content Module Editor) for creating and storing document contents,
It is characterized by comprising a user manager (User Manager) for managing the class of the reader and the creator, the grant of reference authority, and the like.

In addition, the present invention assists the user in inputting,
An input field generator (Inp.) That manages stored information and supports output, and provides an automatically generated input format.
ut Field Generator), an explanation generator (Explanation Generator) that enables online explanation, an information repository (Repository) that maintains information on the project, life cycle, documents and related information in a database, and a document An output generator for connecting and using a web browser for searching.

The software document creation system according to the present invention is characterized in that a document serving as a unit for storing and processing a document is defined by a document model having a tree structure. Tools that take the traditional view of a document as a collection of characters are easier to develop because the document is associated with a file and all operations are performed on a file or character basis, but the user is Since it is necessary to understand the structure, it is difficult to use it.In addition, since only one document is managed individually, it is difficult to manage the dependencies between documents or the position of documents in a project. is there.

In the present invention, by expressing a document in a tree structure, a hierarchical structure of chapters, sections, paragraphs, etc. can be well expressed. The nodes of the tree constituting the document tree are classified into two types, hierarchical information and content modules. The hierarchical information node is a portion corresponding to the table of contents of the document, and is a portion that expresses the structure of the document such as a chapter, a section, and a paragraph of the document. With the document title as the root node, the chapter, section, and paragraph titles form one node each. The content module node represents the actual content of the actual document in text or graphics. One or more content modules exist below the hierarchy information. In the present invention, not only creation and modification of documents, but also life cycles and documents are defined from the overall viewpoint of the project, and the life cycle hierarchy (L
ifecycleLayer), document layer (Document Layer), template layer (Template Layer), content module layer (Content Mod
ule Layer) is set.

In the life cycle hierarchy, management information for a project is defined, and then a life cycle as a procedure for executing the project and a generated document as a product of the life cycle are defined. In the document hierarchy, detailed management information relating to the document defined in the life cycle hierarchy is input, and the document creation order, inter-document dependency, and the like are defined so that they can be referred to in the next stage, the template hierarchy. The template layer sets the position and direction of the contents to be input in the stage of defining the structure of the document. A document structure in the form of a tree is defined, and when the defined hierarchical information node should have a reference relationship with the hierarchical information node of another document, a reference link is set and linked.

In the content module hierarchy, actual content is input to the document structure defined by the template hierarchy. That is, the hierarchical documentation model is composed of the upper three layers that define the structure of the document and the position of the document in the entire project, and the lower one layer that actually creates the document based on the defined document structure. These layers have characteristics sequentially in time, and the information of the upper layer has higher priority than the information of the lower layer. The above hierarchical documentation model has the following features. First, systematic management of life cycle and generated documents is possible. In other words, the units for generating and managing documents are divided into four layers, namely, life cycle hierarchy, document hierarchy, template hierarchy, and content module hierarchy, and their roles are distinguished by hierarchy, and projects, life cycles, documents, document structures, contents The following systematic creation and management of documents is possible.

Second, independent documentation for a particular methodology is possible. In other words, the waterfall model is a basic life cycle model, but by defining and using the life cycle and generated documents in the project, it is possible to accommodate all of the many transformation methodologies of the waterfall model, Documentation that does not depend on a specific methodology is possible. Third, it helps maintain consistency between documents in the overall perspective of the project. There is a reference link for each hierarchy except the life cycle hierarchy in the hierarchical documentation model, and the reference link in the upper hierarchy acts as a guide and control for the reference link in the lower hierarchy,
It has abstracted information for the lower hierarchy reference link. Therefore, a document creator can easily and accurately search for and refer to a relevant part of another document by using a reference link at the time of document creation, and can maintain documentation between all documents in a project. .

Fourth, the hierarchy of the document structure is reflected. The hierarchical documentation model uses a tree material structure to model the document structure. By expressing the document structure in the form of a tree, it is possible to express well the hierarchy of chapters, sections, paragraphs, and the like. The present invention is characterized in that reference links are set for each layer using the above-described document structure and document model to maintain document consistency. The upper-layer reference link acts as a guide for the generation of the lower-layer reference link, and when the lower-layer reference link changes, reflects and controls the result. Therefore, the reference link of the upper layer has the abstract information of the reference link of the lower layer, and by using this, the user can grasp and manage the reference link from the viewpoint of the entire project. Further, the documentation management support system realized by the present invention forms a link for linking related documents when generating an HTML file using reference links, so that a related document can be easily searched when searching using a web browser. Can be extracted and searched.

The reference links defined in the present invention exist in the remaining three layers except the life cycle hierarchy (the dependency between life cycles is not separately defined, and the order in which the life cycles are defined is used as it is. Assume that the current life cycle stage is dependent on all previous life cycles). That is, a reference link between document hierarchies that plays a role of indicating a dependency relationship between documents and a creation order between documents, an automatic document reference link that is automatically generated by the system by reflecting a link between template layers, When a module is created, it has a template reference link indicating the part to be referred to in other documents and summary information for the reference link in the content module hierarchy. A template hierarchy automatic setting reference link automatically set by the system to reflect on the hierarchy, and a content module reference link for directly connecting the module and the content module so that the reference is not actually performed.

According to the present invention, a search for a related document is supported by using reference links set for each layer of the hierarchical document model, and when a link is set or deleted, the result is reflected on all layers. The feature is that reference links are managed as described above. That is, when setting the reference link, the document creator grasps the relationship in the lower hierarchy in which the relationship is set in the document hierarchy, the template hierarchy, and the content module hierarchy, and the system generates the upper hierarchy link, and A function to place another content module in between and, when an intermediate module is deleted when there is an indirect reference, reflect that information on the template layer and document layer to indicate that the indirect reference has been made It is characterized by having.

Further, the present invention is characterized in that a template is used in order to supplement the inconvenience of defining and using documents one by one every time a project is performed. A template means a type, a structure that includes a project, life cycle, document relations, and document contents, and serves as a kind of guideline for the project. Thus, when the document manager defines a document, consistency of the document structure can be maintained. If the template supported by the present invention is stored in a template independently for only one document, the dependency information between documents or the dependency information between hierarchical information cannot be expressed. Assist in loading and modifying within the called template. The template database is another table for storing information necessary to represent a template among information repository configuration contents, and is composed of a part of a table structure in the information repository (having a structure for storing reusable information). ) Stored in the database of documentation management support tools, and the necessary files are stored in a directory called templates.

According to the present invention, after the project is advanced, the life cycle and the documents belonging to the life cycle, and the structure and content module of each document can be stored in the form of a template. That is, all information related to the current project is copied and stored from the project table to the project template table, from the life cycle table to the life cycle template table, from the document table to the document template table, using the code of the current project as a key value. In addition, since the content modules are stored in the form of files, all content module files related to the current project are copied to the template directory. It is characterized in that the user gives a name to the copied information so that when another project progresses, the project progress stage or the structure of the document can be reused.

[0019]

DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram of a software document creation apparatus according to the present invention. As shown in the figure, a software document creation system analyzes a user interface 1 for input and retrieval, management of document contents and meta information. A document management unit 2 for processing document generation, an output generation unit 3 responsible for output, and an information repository management unit 4 for connection to an information repository. The user interface 1 is realized using Visual Basic based on Windows. An input form automatically generated by the input field generator 12 is provided,
The description generator 11 is used as a user interface so that online description is possible.

The documentation manager 2 is a kernel part of the software document creation device. The life cycle manager 21 sets the stage of the life cycle and determines the type of the document without depending on a specific methodology. The document management device 2 includes a user management device 24 that manages the class of the viewer, the grant of reference authority, and the like so that the definition can be defined. Content module editor 23 for creating general text information
There is also a link for graphic editors.
The relationship manager 22 sets the relationship between the documents in cooperation with the life cycle manager 21 and the user manager 24, sets the individual structure of the document, and sets the relationship between the document contents. And the like to manage reference links.

The output generator 3 is used for searching for a document.
In order to connect and use the web browser, it performs a function of analyzing information in a database of an information storage and outputting it to an HTML file. In addition, the HTML file has a graphic file generator for generating a graphic file in order to store the graphic file separately and to link the graphic file.

The information repository manager 4 stores and processes all information handled in a hierarchical documentation model using a relational DBMS to maintain information on projects, life cycles, documents and related information in a database. A possible structure was constructed in a table format. In addition to the database, it also manages HTML files and graphic files created by the output generator.

Tables 1 and 2 describe the configuration forms and functions of the software document creation device (Tables 1 and 2 are integrated). The software document creator is realized using Visual Basic in the environment of Windows 95. In this Visual Basic, most of the processing is created and executed around a form. Therefore, each function required by the system is composed of one or more forms. Attributes, events, and procedures are defined and created for each form, and the forms are linked to complete a complete program. I do. In Tables 1 and 2, the initial screens include smds, which is the basis of the user interface, and fpronew, f
proopen, flifecycle, flifede, fdoc, fdocde, fnewtr
The eight forms of ee, fuptree perform the functions of life cycle manager 21. Reference links are managed by fdoclink, ftre
Performs in two forms of elink. The fdoclink form sets and manages inter-document reference links, and the ftreelink form sets and manages inter-layer reference links.

The forms constituting the content module creator are roughly divided into two types. One is frmwordpad, which performs the function of creating a text module, and the other is frmOLE, which performs the function of creating a graphic module. FrmModuleTyp connects these two forms
e In the form, call the appropriate content module creation form according to the user's selection. The database.bas file has no form directly visible at runtime, but defines procedures and variables, constants, etc. that can operate on the information repository database, and the filopn.bas file contains procedures related to file input / output. The template.bas file has procedures for storing and loading templates, and the html_module.bas file has procedures for generating HTML files.

[0025]

[Table 1]

[0026]

[Table 2]

FIG. 2 shows a part of a function requirement document prepared according to the KS (Korean Industrial Standard) documentation guideline, and shows the structure of a general document by a practical example. FIG. 3 maps FIG. 2 to a tree-structured document model used in the system. The nodes of the tree constituting the document tree are classified into two types, hierarchical information and content modules. Those represented by solid rectangles in FIG. 2 are hierarchical information nodes. The hierarchical information node is a portion corresponding to the table of contents of the document, and is a portion expressing the structure of the document such as a chapter, a section, and a paragraph of the document.
With the document title as the root node, 1, 1.1, 1.1.
Titles of chapters, sections, and paragraphs such as 1, 2, 2.1 form one node. The content module nodes are represented by dotted rectangles in FIG. 3 and indicate the actual content of the text or graphic data of the actual document. One or more content modules exist under the hierarchy information.

FIG. 4 shows the overall structure of the hierarchical documentation model. In the hierarchical documentation model, documentation proceeds in four layers. First, in the life cycle hierarchy, after defining management information for a project, a life cycle which is a procedure for executing the project and a generated document which is a product of the life cycle are defined. In the document hierarchy, detailed management information related to the document defined in the life cycle hierarchy is input, the document creation order, inter-document dependency, and the like are defined so that the document hierarchy can be referred to in the next stage, the template hierarchy. The template hierarchy sets the position and direction of the input content at the stage of defining the structure of the document.

A document structure in the form of a tree is defined, and when the defined hierarchical information node should have a reference relationship with the hierarchical information node of another document, a reference link is set and linked. In the content module hierarchy, actual content is input to the document structure defined by the template hierarchy. That is, the hierarchical documentation model is composed of a document structure and three upper layers that define the position of the document in the entire project, and one layer that actually creates the document based on the defined document structure. This layer has a sequential characteristic in time, and information of a higher layer has higher priority than information of a lower layer.

Table 3 shows the functions for each layer and the information stored and managed in the hierarchical document model. The life cycle hierarchy is a hierarchy that defines general definitions for a project, and performs two functions, project definition and life cycle stage definition. That is, in the life cycle hierarchy, after defining general matters for the project, a life cycle, which is a procedure for performing the project, is defined. At this time, general items such as a stage name, a person in charge, a period, and the like for each stage of the life cycle and documents generated for each stage are listed. The information set in the life cycle hierarchy is a range of values referred to in the lower three hierarchies. As an example of project configuration personnel, information on personnel once input in the life cycle hierarchy is a population of the document creator and the document viewer setting in the lower hierarchy (document hierarchy, template hierarchy, content module hierarchy). That is, only the persons input here have the authority to participate in the project activity, and if a change occurs in the lower hierarchy, that information is immediately reflected in the upper hierarchy.

The document hierarchy is a hierarchy for performing a general definition for the software life cycle-based output document defined in the life cycle hierarchy. The reference link represented by the arrow in FIG. 4 indicates that there is an inter-document dependency. For example, in FIG.
doc1 and doc3 of e1 are both linked to doc2. This indicates a dependency that doc2 should be created with reference to doc1 and doc3 when it is created. In addition, since doc1 and doc3 must be completed in order to create document doc2, they also serve to display the order of creation between documents. The template hierarchy is a hierarchy that defines the structure of a document.

A document has a tree-shaped structure. After defining the structure, if the defined hierarchical information node should have a reference relation with the hierarchical information node of another document, Connect with the hierarchy information node by reference link. The content module hierarchy is a hierarchy in which a document creator inputs actual contents into the document structure defined by the template hierarchy. The document creator has entered the life cycle, document,
The position of the content module to be created is selected based on the information on the document structure, and the actual content is input. The documentation support tool browses the related content module using the reference link of the upper hierarchy, and creates a document by referring to the module. Therefore, consistency between related documents can be maintained.

[0033]

[Table 3]

FIG. 5 shows an example of a hierarchical reference link. The upper-layer reference link acts as a guide for the generation of the lower-layer reference link, and reflects and controls the result when the lower-layer reference link changes. Therefore, the reference link of the upper hierarchy has the abstracted information for the reference link of the lower hierarchy, and by using this, the user can grasp and manage the reference link from the overall viewpoint of the project.
Reference links exist in the remaining three layers except the life cycle layer. Dependencies between life cycles are not separately defined, and the order in which the life cycles are defined is used as it is. That is, assume that the current life cycle stage is dependent on the previous entire life cycle. The link of the document hierarchy shown in FIG. 5 indicates that there is inter-document dependency. In other words, this indicates that there is a dependency between different pieces of hierarchical information in the template layer that is the lower layer. Also,
Since a document can be referred to only after the referenced document is completed, it also serves to indicate a document creation order.
FIG. 5 shows that there is a dependency between document A and document B, and therefore document B should be created after document A is completed.

In FIG. 5, the reference link between the hierarchy information (the link of the template hierarchy) plays two major roles. One role is to indicate a part to be referred to in another document when the content module is created. When creating a content module, a document creator can easily search for a document to be referred to by using a browsing function provided by a documentation support tool. Another role is to have summarized information for reference links in the content module hierarchy.
When there is a change in the reference link in the content module hierarchy, the change is reflected in the template hierarchy, and the link in the template hierarchy also changes.

In FIG. 5, there are three reference links in the template hierarchy. The reference link indicates that the hierarchy information A3 and B3 and the hierarchy information A6 and B5 generated by the document manager have a dependency relationship, and indicates a part to be referred to when the content module is created. The reference link is a link automatically generated by the system to accommodate the change of the reference link in the content module hierarchy. When creating the content module c2, b
2, a reference link is generated, and a reference link is generated by reflecting this in the template hierarchy, and the reference link is also a link automatically generated by the system for the same reason.

In FIG. 5, a reference link between content modules (a link in the content module hierarchy) directly connects the content module actually referred to and the content module.
There is a reference link between content modules a2 and b1, which indicates that a2 was directly referenced when b1 was created. Therefore, the contents of b1 and a2 need to be created consistently, and when a2 changes, b1 also needs to be modified.

FIG. 6 shows a reference link management method and shows a change in a link when a content module is deleted. When a direct reference is made between the content modules as in a2 → b1 or a3 → b2 in FIG. 5, it is preferable to simply remove the reference link only when deleting the module. However, when the indirect reference is made via b2 as in the case of the content modules a3 and c2 in FIG. 5, when the content module b2 is deleted, a3 and c2 become irrelevant content modules. When b2 is deleted, the software document creation device reflects the information on the template layer and the document layer, and a3 and c
Display an indirect reference relationship between the two. That is, in FIG. 5, when b2 is deleted, the reference link connected to b2 is deleted, and at this time, A6 and C6, which are nodes of the template hierarchy including a3 and c2, are connected. Indicates that an indirect reference has been made between a3 and c2 even if b2 is deleted. And document A and document C
The reference link is connected between them, and the reference link is removed, whereby the reference link is automatically removed. FIG. 6 shows the result of removing the content module b2 of FIG.

Tables 4 and 5 show the schema structure of the document template (combined with Tables 4 and 5). Templates are used to compensate for the inconvenience of defining and using documents one by one every time a project is performed. However, the templates supported by the present invention are stored in templates independently for only one document. In this case, inter-document dependency or inter-hierarchical information cannot be expressed.
Store on a project-by-project basis and assist in loading and modifying from within the loaded template from this repository. The template database is another table for storing information necessary for expressing a template in the contents of the information repository, and is composed of a part of a table structure in the information repository (having a structure for storing reusable information). ) Document management support tools are stored in the database, and the necessary files are stored in a directory called template.

According to the present invention, after the project is advanced, the life cycle and the documents belonging to the life cycle, and the structure and content module of each document can be stored in the form of a template. That is, all information related to the current project is copied and stored from the project table to the project template table, from the life cycle table to the life cycle template table, from the document table to the document template table, using the code of the current project as a key value. . Also, since the content modules are stored in the form of files, all content module files associated with the current project are copied to the template directory. When the user assigns a name to the copied information and proceeds with another project, the project progress stage or the structure of the document can be reused, and a consistent structure can be obtained between different projects or documents. .

[0041]

[Table 4]

[0042]

[Table 5]

FIG. 7 shows the flow of document creation and retrieval in the software document creation system of the present invention. The user of the software documentation system is the document administrator (super-u
ser) and general users. The document manager defines a general content (life cycle, document, document structure) in which the project proceeds (S1xx).
Step), the general user creates a document according to the document structure defined by the document manager, searches and outputs the created document (S2xx step). In order to define a document, a definition of where the document is located in the project must first be made. That is, after confirming the user with the document manager (S101), the definition for the project is performed (S103), and then the definition for the life cycle is performed (S105). At this time, when performing a new project, user information is input (S102).
When an existing project is called, the project information is confirmed (S104). After defining the document (S107 to S109), the document structure is defined (S110, S111).

The process from the project definition to the document structure definition is called a document definition, and is performed by a document manager. In the step of defining a document, necessary documents are defined for each life cycle stage (S107), a relationship between the documents is set (S108), and the document for each life cycle stage is confirmed again (S109). In the step of defining a document, the structure of each document is divided into chapters, sections, and paragraphs to define a tree structure (S110), and a relationship between each substructure is set by a link (S111). After confirming the user (S201), the document creator (general user) creates a content module on the defined document structure (S202). When a "content module new creation button" is pressed on the document structure definition screen, an editor appears on the screen, and the contents of the document are created using the editor. The completed contents are automatically stored in a database, and the system analyzes the generated contents and creates an HTML file (S206). At this time, if the contents are in the form of text, a text editor provided by SDMS is used, and the contents of the graphic form are used by linking the graphic editor using the OLE function.

At the time of document creation, a related document can be referred to in order to maintain consistency with the related document (S203). When the system generates the HTML file, if a special form is desired, the format of the document can be separately defined (S20).
5). When a search is selected in the menu window to search for a document (S204), document browsing (S207) or keyword search (S208) is possible. At the time of document browsing, whole browsing (S209) or partial browsing (S210) is possible. In the keyword search, a document keyword search for searching the document (211) or a content module keyword search for searching the content module can be performed (S212).

[0046]

As described above, according to the present invention, in software development, software is developed while setting a hierarchical structure and relationships that are independent of development methods and procedures and can maintain consistency. All industrial entities (system integrators, software houses, in-house developers) can easily create various documents that are products generated during the software development process, and maintain and manage them with consistency And a method of operating the same.

[Brief description of the drawings]

FIG. 1 is a configuration diagram of a software document creation system that implements the present invention.

FIG. 2 is an exemplary diagram of a software document of the present invention.

FIG. 3 is a document structure diagram of the present invention.

FIG. 4 is a structural diagram of a hierarchical documentation model of the present invention.

FIG. 5 is a conceptual diagram of setting a reference link for each layer according to the present invention.

FIG. 6 is a change diagram of a reference link when a content module is deleted.

FIG. 7 is a processing flowchart of the present invention.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 User interface 2 Documentation manager 3 Output generator 4 Information repository 11 Explanation generator 12 Input field generator 21 Life cycle manager 22 Relationship manager 23 Content module editor 24 User manager

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Bek Du Kwon Modern apartment 102-402 (72) Incheon, Gangnam-gu, Seoul South Korea Inventor Na Hong Suk 88-20 (72) Invention, Punnap-dong, Songpa-gu, Seoul Zhan Song Bong 766-22 Dan-dong, Gumpo, Gyeonggi-do, Republic of Korea

Claims (8)

[Claims] 1. A user interface (1) for inputting and retrieving, a document manager (2) for managing document contents and analyzing meta information to process document generation, and an output for document output. Using a hierarchical structure and relationships of software documents characterized by comprising a generator (3) and an information repository manager (4) for maintaining information on projects, life cycles, documents and related information in a database. Software documentation system. 2. An explanation generator (11), wherein said user interface (1) is capable of providing online explanation.
2. The software document creation system according to claim 1, further comprising an input field generator for providing an automatically generated input format. 3. The life cycle manager (21), which is capable of defining the stage setting of the life cycle and the type of the generated document without depending on a specific methodology.
A relationship manager (22) responsible for maintaining document consistency and a content module editor (2) that enables creation of general text information and also links such as graphic editors
3) and a user management device (24) for managing the class of the viewer, the grant of reference authority, and the like.
A software document creation system using a hierarchical structure and relationships of the described software documents. 4. A document which is applied to an input field generator (12), a content module editor (23), and a relation manager (22) to define a document as a unit for storing and processing the document in a tree structure, A node corresponding to the table of contents of a tree, the hierarchical information representing the structure of the document, such as chapters, sections, and paragraphs of the document, and a content module indicating the actual contents of the actual document in text or graphics. 4. The software document creation system according to claim 2, wherein the document model is defined in a document model having a tree structure divided into two types. 5. The invention is applied to the life cycle manager (21) and the relation manager (22), and defines a life cycle and a document from the viewpoint of not only creation and modification of the document but also a project as a whole, and determines the relationship between the documents. 4. A software document hierarchy using a software document hierarchy and relationships as set forth in claim 3, wherein a four-layered documentation model that can be expressed is a life cycle hierarchy, a document hierarchy, a template hierarchy, and a content module hierarchy. A software documentation system that uses structures and relationships. 6. A reference link is set for each hierarchy using the document structure and the documentation model, and at the time of setting the reference link, a document creator sets a relationship between a document hierarchy, a template hierarchy, and a content module hierarchy. When the system creates a link in the upper hierarchy by grasping the relationship in the lower hierarchy to be created and the intermediate module is deleted when there is an indirect reference by placing another content module between the content modules, the information is deleted. 6. The software document creation system according to claim 4, further comprising a function of displaying that the indirect reference has been performed by reflecting the indirect reference to the template layer and the document layer. . 7. A software document creation device that supports storing, recalling, and copying of templates to complement the inconvenience of defining and using documents one by one each time a project is performed. A software document creation system that uses a hierarchical structure and relations of software documents as features. 8. An operation method applied to a software document creation device, wherein a document manager defines a general content (life cycle, document, document structure) in which a project proceeds (S101 to S111). The general user creates a document according to the document structure defined by the document administrator, searches for the created document, and outputs the document (S20).
1 to S212), a method for operating a software document creation system using a hierarchical structure and relationships of software documents.