JP2006221316A - Project management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To manage the requirements for a whole product and changes to components such as software modules in association with each other in a reliable fashion and to easily obtain the progress for the whole product on the basis of the working condition of a person in charge about the components. <P>SOLUTION: This project management system has a process for managing the hierarchical structure of the components; a process for allocating the requirements to be achieved to higher-level components; a process for allocating the requirements to be achieved to subordinate components by selecting the requirements from the requirements allocated to the higher-level components; a process for updating the status of achievement of the requirements allocated to the subordinate components, as the revision of the components is updated; and a process for calculating the status of achievement of the requirements for the higher-level components according to the results of the processes. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a project management system that supports development management such as software development, and more particularly to a system that manages requirements to be achieved in development and schedules and results of defects to be solved.

  In project management, it is important to manage the list of requirements to be achieved, various troubles, etc., and the schedules and achievements of achieving and solving them. From this perspective, many project management systems have been devised. I came.

  In recent years, in order to respond flexibly to customer requirements, it has been required not only to develop a single product but also to develop many derivative products based on it. Therefore, it is necessary to develop and ship a large number of versions in order to correct defects and add / change requests after testing and shipping or during development.

  For this reason, development of common parts aimed at sharing modules among multiple products, and diversion development to develop new versions and derivative products by modifying existing modules of past products, etc. have been actively carried out. It is coming.

  In such shared development and diversion development, since many products and many versions are developed by combining many common modules and diversion modules, requirements to be achieved and problems to be solved in these many products and versions are scheduled. And the actual results, that is, whether the planned requirements for the product as a whole have been achieved, whether the defects have been resolved, and the corrections made to each module are accurately managed and thoroughly communicated to developers and related parties. is important.

  For this reason, although it is an example of a hardware, in patent document 1, a permanent change based on the technical improvement with respect to the component which comprises a product, and a change based on a customer request are managed, and various based on them. Systems have been proposed that can manage the correct product configuration and track changes made.

Japanese Patent Laid-Open No. 5-189445

  However, in the above-mentioned patent document 1, only the change result is managed, and no support can be provided for the work up to the result.

  In particular, the schedule of what version and what version of the product will be changed is not managed, and the creation of the schedule is not supported.

  Further, in such shared and diverted development, it is often necessary to make modifications to many other products and previous versions, and support is also required in such cases.

  In addition, previously realized requirements may be deleted or changed in a new product or version. In such a case, management must be performed so that the requirement is surely deleted or changed.

  In addition, it is desirable to manage such many changes in association with changes in the source code of each module in the case of software components, such as software components, which are entities subject to change.

  In view of such problems, the present invention has the following objects.

  ・ Support the requirements and achievements to be achieved and the problems to be solved in many products and many versions.

  -Manages the schedule and performance of modifications of a number of components that make up the product, and supports the correspondence between the requirements and achievements to be achieved for the entire product. It also supports the association with correction work such as source code.

  ・ If a problem occurs, support the need for and countermeasures for other products and previous versions.

  • Helps ensure that corrective actions are taken when changes or deletions of previously fulfilled requirements are required.

  The project management system according to the present invention includes a process of managing a hierarchical structure of components, a process of assigning requirements to be achieved for the higher-level components, and a requirement to be achieved for its descendant components. A process of assigning among the requirements to be achieved assigned to the higher-level component, a process of updating the achievement status of the requirements to be achieved assigned to the descendant component as the component revision is updated, and And calculating the achievement status of the requirements to be achieved for the higher-order component based on the above.

  According to the present invention, the requirements for the entire product and the changes to the components such as the software module can be reliably associated with each other, and the progress status of the entire product can be easily grasped from the work status of the person in charge for the component. The effect that it can do is acquired.

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

<Embodiment 1>
FIG. 1 shows the basic configuration of the present invention.

  In FIG. 1, Aa and A-2 are computers serving as clients, and A-3 is a computer serving as a server, which are connected to each other via a network. The server computer A-3 has a database A-4 for managing data, and a server program operates.

  The server program in the present invention is constructed as a Web application, for example. That is, the client is a general-purpose Web browser, and exchanges with a program running on the server using the HTTP protocol.

  As another configuration, the server machine operates only a general-purpose database management system (DBMS) for managing the database, and the client program according to the present invention operating on each client directly accesses the database A-4. But it ’s okay.

FIG. 2 shows a conceptual data structure of data stored in the database A-4. The arrows in the figure indicate that there is a one-to-many relationship between the data in the direction of 1 → many.
B-1 is a requirement related to the target product group, B-2 is a target product, B-3 is a version of the product, B-5 is a component related to the target product group, and B-6 is a component revision. It is data to represent.

  B-8 is component configuration data indicating the configuration of component revisions in a certain product version.

  In the following description, it is assumed that the product and its version, and the component and its revision are in the relationship as shown in FIGS.

  FIG. 3 shows an example of the product version system. First, there are two products P1 and P2, and the product P1 has three versions v1.0, v1.1, and v1.2. The direction of the arrow in the figure indicates the order of version creation. Version v1.1 is created based on v1.0, and v1.2 is created based on v1.1.

  Further, v1.0 of the product P2 is created based on the version v1.0 of the product P1, and v1.1 is based on two of the previous version v1.0 of the product P2 and the version v1.1 of the product P1, that is, It shows that two product versions are merged and created.

  Note that + RX. The meaning of X will be described later.

  Similarly, FIG. 4 shows an example of a system of components constituting a product. First, there are components C1 and C2, and the component C1 has four revisions r1.0, r1.1, r1.2, and r1.3. . Here, the meaning of the arrow is the same as in FIG. 3, and for example, r1.2 indicates that it is created based on r1.1. The component C2 includes two revision sequences of revisions r1.0, r1.1, r1.2, r1.3 and revisions r2.1, r2.2, r2.3 derived from r1.0 created in this order. In particular, r2.2 has an arrow from r1.2 to indicate that two revisions r2.1 and r1.2 have been merged.

  Similar to FIG. 3, + RX. The meaning of X will be described later.

  In FIG. 2, requirement B-1 is, for example, each of external or internal functions and performances and should be realized by development. Here, all the requirements of the target product group are managed and added every time a new requirement is generated.

  FIG. 5 shows an example of a list of requirement B-1. Each requirement has a requirement ID for identifying it and a title as attributes. Other details and supplemental attributes may be included.

  Also, since the requirements are very large, it may be used for searching or the like with attributes for classification.

  Here, assuming that the requirements are classified and organized hierarchically, in FIG. 5, the hierarchical structure is shown by the indentation and requirement ID symbols R1, R1.1, R1.1.1,. Moreover, the arrow which goes out of requirement B-1 and enters B-2 in FIG. 2 shows this hierarchical structure. The hierarchical classification of requirements is not essential.

  In FIG. 2, product data B-2 manages the product name, product content, etc., and is added for each new product.

  The products that have been improved or corrected are shipped several times, each of which is a product version B-3.

  An example of product version data B-3 is shown in FIG.

  The product version data has the product name and version name as keys, and has the status of the product version and parent version information on which the product version is based as attributes.

  For example, the status of the product version takes one value from “planned”, “under development”, and “shipped”.

  In addition, an intermediate version other than that which has been shipped may be provided in order to determine the configuration at the time of testing or the like. In this case, for example, a value of “test” may be added to the status.

  The parent version information is a list of product versions on which the product version is based, that is, a list of key values (product name, version name), and has a relationship indicated by an arrow B-4 in FIG.

  The content of FIG. 6 is based on the example of the product version system of FIG. 3. For example, development of version v1.2 of product P1 is scheduled based on version v1.1 of product P1, and version v1 of product P1 is planned. Version v1.1 of product P2 based on .0.0 is under development.

  The meaning that the parent version information is not a set (product name, version name) but a list will be described in the third embodiment.

  In FIG. 2, a component B-5 is each of all components related to the target product group, and has a component name and its description as attributes, and data is added every time a new component is added.

  Here, the component is a module used in a product in the case of software development, but may include other documents related to development such as functional specifications and test specifications.

  Component B-5 is managed in the course of development because its function addition and defect correction are performed sequentially, so that revision B-6 is managed.

  FIG. 7 shows an example of component revision data B-6.

  In FIG. 7, the component revision has (component name, revision name) as a key, and the status of the revision, parent revision information, and the like as the product version.

  The revision status takes, for example, one value of “planned”, “under construction”, and “created”.

  Here, “scheduled” means that the revision does not yet exist as an entity, and the creation work has not started. “Creating” indicates that the work is being created. In particular, when a new revision is created by correcting the previous revision, the previous revision is checked out.

  “Created” indicates that the revision is actually created and exists, and is a so-called checked-in state.

  Like the parent version information of the product version, the parent revision information is a list of revision names that are the basis of the revision, and has a relationship indicated by an arrow B-7 in FIG.

  Here, assuming that revisions are not created based on revisions of other components, a list of only revision names is used instead of a list of (component name, revision name).

  The contents of FIG. 7 are based on the example of the component revision system of FIG. 4. For example, each revision has been created in the order of r1.0 → r1.1 → r1.2 in the component C1, and r1.2 Based on this, r1.3 is scheduled to be created.

  As in the case of the product version, the meaning that the parent revision information is not only one revision name but also a list will be described in the third embodiment.

  The component / revision data may have other attributes such as a person in charge of creating the revision, a creation date / time, and a comment regarding the correction contents.

  In FIG. 2, B-8 is component configuration data indicating the configuration of the component revision in a certain product version.

  FIG. 8 shows an example of the component configuration data. The version v1.0 of the product P1 is composed of the revision r1.1 of the component C1 and the revision r1.0 of the C2, and the version v1.1 of the product P2 is the revision of the component C1. It shows that it consists of r1.3 and C2 revision r2.2.

  The component revision configuration of this product version is confirmed when the status of the product version is shipped, but if the status is planned or under development, the revision of the component revision accompanying the creation / modification of each component It depends on.

  In FIG. 2, B-9 is product version requirement data indicating requirements to be realized in each product version. FIG. 9 shows an example of this data.

  Product version requirement data has (product name, version name, requirement ID) as a key, and has a corresponding status attribute for managing the corresponding status of the requirement in the product version.

  When the requirement data of B-1 is classified hierarchically, this requirement ID is set only for the leaf node at the lowest layer.

  For example, the correspondence status takes one value of “planned”, “incomplete”, “corresponding”, and “unrelated”.

  Here, “schedule” should fulfill this requirement in this product version, but it has not yet been realized, “already supported” has been realized, and “unfinished” has been implemented to realize it. Indicates that it has not been fully realized due to a defect.

  “Unrelated” means that product version requirement data does not actually exist for this product version and requirement, or that this product version and this requirement are irrelevant even if data exists, for example, the schedule was later deleted It is used in cases such as when clearly indicating in the case of.

  In FIG. 9, for example, version v1.0 of the product P1 indicates that two requirements R1.1 and R1.2 have been handled. The version v1.1 of the product P1 indicates that the two requirements R1.3 and R1.4 are already supported.

  Here, it is assumed that the product version requirement data is created by the difference between the product version and the parent version. That is, since the parent version of the version 1.1 of the product P1 is version v1.0, the requirements R1.1 and R1.2 have already been dealt with, and in addition to that, R1.3 and R1.3 have been dealt with. Indicates that

  These relationships are shown in FIG. X indicates that the requirement on the arrow connecting the product versions is realized in addition to what has been realized in the previous version in the development during this period.

  That is, the product version requirement data is created only when a requirement that is not in the parent version is assigned compared to the parent version, or when the same requirement as the parent version is assigned but the corresponding status is different. The

  In addition, there may be a case where a so-called “degeneration” occurs, for example, a problem occurs in a requirement that has been dealt with previously due to the addition of a new requirement. The response in such a case will be described later in the second embodiment.

  In FIG. 2, B-10 is component revision requirement data indicating requirements to be realized in each component revision, and FIG. 10 shows an example of this data.

  Each component revision requirement data has (component name, revision name, requirement ID) as a key, and has a corresponding status attribute for managing the corresponding status of the requirement in each component revision.

  For example, as in the case of the product version requirement, the correspondence status takes one value of “planned”, “incomplete”, “corresponding”, and “unrelated”.

  Also, this data is managed as a difference with respect to the parent revision as in the case of the product version requirement.

  In FIG. 10, for example, the revision r1.0 of the component C1 should correspond to the requirements R1.1 and R1.2, but R1.1 is “incomplete”, that is, still incomplete, This indicates that “scheduled”, that is, nothing has been done yet, and that these two requirements have been met in revision r1.1.

  Further, the revision R1.2 of the component C1 requires further correspondence to the requirements R1.3 and R1.4, but R1.4 is “incomplete” and r1.3 is “corresponding”. It shows that it became.

  As in the case of the product version requirement, this relationship is also + RX. The requirement of X indicates that the corresponding status for the requirement has changed due to the correction work from the previous revision.

  In FIG. 10, for example, the requirements R1.2 and R1.3 are related to the two components C1 and C2. However, the requirements for the entire product and the components that need to be dealt with for this are general. It becomes a many-to-many relationship.

  The following describes user operations and processing in the system.

  First, a “counting of corresponding status” function is defined. This takes a list of values of the corresponding status of the product version requirement or the component revision requirement, and returns one value of the corresponding status as the total result.

  For example, the value of the corresponding status may be regarded as having a magnitude relationship that increases in the order of “planned”, “incomplete”, “corresponding”, and “unrelated”, and the minimum value may be obtained from the list. If the list is empty, “unrelated” is assumed.

  Next, a function “get corresponding status of product version requirement” is defined.

  FIG. 11 shows the flow. This function takes (product name, version name, requirement ID) as arguments, obtains the corresponding status of the requirement of the requirement ID in this product version, and returns a set of (defined product name, defined version name, supported status).

  As mentioned above, the product version requirement data holds only the difference, so if there is no requirement data for this product version, the product version requirement data is defined by tracing the ancestor product version. Returns a value.

  This is obtained by recursive calling of this function as shown in FIG.

  In exactly the same way, for a component revision, a “get component revision requirement status” function can be defined.

  In the following, when a certain version of a product is shipped and new requirements such as enhancements are added based on this, the next version, or the first version of a different system with different platforms and target users will be developed. To do.

  In this case, using the project management system according to the present invention, the person in charge of development and the development manager work in the following procedure.

  S1: In the case of a new product, product data is added.

  S2: A product version to be developed is added.

  To do this, the system displays a list of product names, selects them, and enters a version name.

  Check for duplicate version names and add new product version data to the database.

  The parent version of this data is the specified product version, and the status is “planned”.

  S3: Enter the requirements to be realized in the product version with the added status “scheduled”.

  The system uses the “obtain product version requirement correspondence status” function of FIG. 11 to display a list of requirements that are not supported by this product version from the requirement data, and select a plurality of requirements. If there is no requirement data, let it be added.

  For each selected requirement, the system adds product version requirement data with its corresponding status = “planned”.

  S4: Create a component revision configuration that is the initial state of this new product version.

  For this purpose, the system creates, for example, a branch revision of each component with status = “planned” based on the component revision configuration of the parent product version, and adds it to the component revision data.

  In addition, these component revisions are registered as initial data of the component configuration for this product version.

  In this process, it is necessary to decide what to do with the initial revision of each component based on the results of the overall review.

  For example, a component may want to use the same revision as its parent product version, or it may be better to create a branch revision from revisions in other products.

  In such cases, let the user modify the revision of each component.

  In addition, as component information, it may be determined that some latest information is always used regardless of the parent product version, and the initial revision may be set accordingly.

  S5: Next, the component revision requirement for each component is input.

  This is done by the person in charge of each component, for example. The person in charge of the component must examine and determine the combination of the component and requirement that must be corrected in relation to each component from the newly added product version requirement. For this purpose, the system displays a “component requirement status screen” as shown in FIG.

  In FIG. 12, a list of current component revisions in this product version is displayed in each row, and requirements set for each component revision and the corresponding status are displayed.

  In the requirement and correspondence status column of the figure, for each requirement ID of the product version requirement in this product version, the correspondence status in this component revision is obtained by the “obtain component revision requirement correspondence status” function, and the value is “ Requirement ID, requirement name, and acquired corresponding status value other than “unrelated” are displayed.

  The total correspondence status in the figure is a correspondence status that does not depend on individual requirements in each component revision, and is a value obtained from the correspondence status for each requirement by the “total correspondence status” function.

  Since no component revision requirement is registered at first, “Unrelated” is displayed in the aggregation correspondence status column of each row, and only the <Add> button is displayed in the requirement column. When the <Add> button is selected, a list of product version requirements for this product version is displayed, multiple requirements related to this component are selected, and component revision requirement data is registered with the corresponding status = "planned" for that requirement ID To do.

  S6: As described above, when the product version requirement is associated with the component / revision that needs to be corrected to realize it, the development is started with the version state of the product version data = “under development”.

  The person in charge of each component performs component correction work and revises revisions several times.

  When the revision is revised, the person in charge displays the screen of FIG. 12 and changes the corresponding status for each requirement assigned to the component to, for example, “incomplete” or “corresponding”.

  If the correspondence status for each requirement is changed, the display is updated by re-aggregating the values in the aggregation correspondence status column as described above.

  S7: The manager in charge displays the status of the product version under development, for example, a “product version requirement status screen” as shown in FIG.

  Here, the product version requirement data and the hierarchical structure of the requirement data B-1 are matched, and the requirements related to this product version are displayed hierarchically in each row.

  Further, from the current component revision configuration and component revision requirement data in this product version, the components, revisions and corresponding statuses associated with each requirement are displayed.

  The total correspondence status column of the figure is a total value of the correspondence status of the related component for each requirement, and is obtained by the above-mentioned “correspondence status aggregation” function.

  For the parent requirement in the hierarchical structure, the aggregation value of the aggregation correspondence status of the child requirement is displayed as the aggregation correspondence status.

  S8: On the product version requirement status screen of FIG. 13, if the total correspondence status of all requirements becomes “Compliant”, the product version is completed.

  The administrator uses the system to determine the component revision configuration for this version by setting the status of this product version to “shipped”.

  In the above description, the product version requirement B-9 and the component revision requirement B-10 in FIG. 2 are managed as differences, but of course, they may not be managed as differences.

  In this case, for example, if there is component revision requirement data assigned to a certain component revision, the requirement data is created with the same corresponding status in the next revision of this component. This method greatly increases the amount of data, but the processing speed is improved because the processing is simple.

  There is also a method of performing difference management partially. For example, if you copy a related component revision requirement to the component revision at the time of shipment of the product version, and the next revision is created based on this revision, For example, differential management is performed only on the allocated requirements.

  In the above description, the product is described as being directly composed of a plurality of components, but of course, it may be managed as a hierarchical structure such as “product-unit-part”. In such a case, a data structure as shown in FIG. 14 is used instead of FIG.

  In FIG. 14, requirement data B-1 manages component names and revision names of all components including hierarchies, that is, products, units, parts, etc., as in FIG. . The contents are the same as in FIG.

  Component configuration B-12 is a parent-child relationship of component revisions, for example, revision 1.1 of product 1 is composed of revision 1.1 of unit 1 and revision 1.2 of unit 2, and revision 1.1 of unit 1 is , Data that holds the relationship of revision 1.3 of component 1. Note that, for example, the revision 1.1 of the part 1 may be shared, such as being used for the revision 1.5 of the unit 1 of the product 2, so that the component configuration B-12 is shared between the component revisions B-11. Is a relation that associates many to others.

  In the example of FIG. 14 as well, the requirements to be realized are basically assigned to the component that is the lowest layer component, and the corresponding status is managed. It is desirable to assign a schedule of requirements for the next revision to be executed, and further assign a schedule of requirements to the lower components sequentially from the requirements.

  After assigning the requirements to be realized to each component in this way, the development is started, and thereafter, as described above, the person in charge inputs the revision status of the lowermost component and the corresponding status of the requirement.

  In operation, for example, by changing the requirement assigned to the middle component to “Compliant”, it is possible to change the corresponding status of the requirement to “Compatible” for all the lower-layer components. .

  As described above, the correspondence status of the requirement of the higher-level component automatically reflects the total result of the correspondence status of the descendant component.

  For example, on the component requirement status screen of FIG. 12, when the person in charge inputs the schedule and results of the corresponding status for each requirement, the period for the corresponding work and the schedule and results of the development man-hour are also entered. For example, the period and the development man-hour for each requirement in the product version, or the period and the development man-hour for the entire product version can be automatically tabulated.

  Further, instead of the corresponding status, the actual result may be input as a numerical value such as a progress rate.

  In addition, development work includes work other than creating and modifying components such as “meetings”. In such cases, for example, meeting minutes can be created as dummy components and managed in the same way. .

  In some cases, a plurality of versions of a product or a next version of a plurality of products may be developed simultaneously.

  In such a case, for example, in FIG. 12 and FIG. 13, not only the component revision requirement support status and product version requirement support status for a specific product version are displayed, but also the requirement support status for all product versions currently under development. It is useful to provide a screen that simultaneously displays

<Embodiment 2>
Next, for example, a case where a defect occurs in a shipped product version will be described.

  As a result of failure analysis, it is assumed that there is a problem with two components, and thus the correspondence to the two requirements is incomplete. In practice, this problem is not a problem introduced in component revisions in product versions, but is often a problem that was already present in previous revisions.

  In addition, these components are used in other products, and other products may need to be modified as well.

  In any case, the person in charge must decide which revision of the component in question should be retroactive. For this reason, “defect” is added as an option for the corresponding status, and the magnitude relationship increases in the order of “defect”, “planned”, “incomplete”, “completed”, “irrelevant”. The value shall be obtained.

  When the revision to be corrected is determined, the system changes the corresponding status value of the revision requirement data of the revision to, for example, “failure”. At this time, the system traces all revisions of the descendants of this revision, and if there is revision requirement data for the same requirement, the corresponding status is also changed to “failure”.

  As described above, the status value of the product version requirement data reflects the total value of the corresponding status values of the component / revision requirement data. As a result, the corresponding status of the product version becomes “failure”.

  In this method, there is a problem that the corresponding status value of the requirement data is changed and the previous value is not known. In order to cope with this, the corresponding status value before the product version requirement data and the component revision requirement data is stored. There is also a method of thinking that the problem is the same as the requirement because the problem is a problem to be solved. That is, information on the defect that has occurred is added as the requirement data of B-1 in FIG.

  Next, the requirement data for the defect requirement is added with the corresponding status = “defect” for the component revision that caused the problem.

  By tracking the descendants of this revision and the product version that uses it, the system can point out what might be present.

  Next, a derivative version of the product version to be modified is created.

  As described above, a branch revision of each component revision is created, but since the corresponding status is “failure” for the component that caused it, this is inherited by the branch revision.

  After that, this problem can be corrected, and the corresponding status should be set to “Supported” in the revised revision.

  It should be noted that this defect requirement data is added as a child data of the defect data where the defect has occurred, or a defect occurs with respect to which requirement by having the defect requirement ID in the defect requirement data. It becomes possible to track what happened.

<Embodiment 3>
A case of supporting so-called “merge” in which a new revision is created from a plurality of different series of revisions will be described.

  In this case, the parent version information in the product version in FIG. 6 and the parent revision information in the component revision in FIG. Accordingly, the “obtain product version requirement correspondence status” function F-1 in FIG. 11 is changed to the flow from F-1 ′ in FIG. That is, in F-7 'instead of Step F-7, the requirement correspondence status is acquired for a plurality of parent versions, and the total value is returned as a result. The “Get Component / Revision Requirement Status” function is also changed.

  When a revision of a component is created by merging two other parent revisions, this revision is already supported for all requirements that have been handled by the two parent revisions.

However, it is a problem whether these correspondence status values are correct, that is, whether the requirements that have already been dealt with by the two parent revisions have been dealt with. The initial value may be set by the following method, for example.
(1) A revision that is a common ancestor of two parent revisions is obtained, and the requirements that have been handled in the common ancestor revision are already handled. Or “incomplete”.
(2) For a set of requirements that have already been handled in each of the two parent revisions, the requirement that is the common set is “corresponding”, and the remaining requirements are “unfinished”.

  In any case, the person in charge will review the details of the component, determine if each of the post-merge requirements needs a new fix or if there is no problem with it, and set the corresponding status value to an appropriate value. Don't be.

<Embodiment 4>
Next, a method for dealing with a case where the requirement itself is deleted or changed will be described.

  For example, if an old function is no longer needed, it is likely to cause problems in later versions if this function is not reliably removed.

  In addition, when the content of the requirement is changed, for example, when the user code that has been 5 digits so far is changed to 6 digits, it is necessary to ensure that this change is supported in later versions. . In other words, the deletion or change of a requirement itself becomes a new requirement. For this purpose, the content of the requirement data B-1 in FIG. 2 is changed from that in FIG. 5 to that in FIG.

  In FIG. 16, three attributes of a requirement type, a target requirement ID, and the number of changes are added to each requirement.

  The requirement type takes three values: “Normal”, “Change”, and “Delete”, where “Normal” is a normal requirement, “Change” is a change in the requirement indicated by the target requirement ID, and “Delete” is a target requirement Indicates that the requirement indicated by the ID is deleted.

  The change count attribute is used for identification because the requirement may be changed several times. For the requirement with the same target requirement ID as “Change” or “Delete” It is assumed that the number is sequentially increased from 1. That is, the largest number is the currently effective change or deletion for the requirement indicated by the target requirement ID.

  In FIG. 16, the XX display requirement of R1.1 has been changed twice, and currently R1.11 is valid, and R1.1 and R1.9 are not valid in gray.

  R1.10 is a requirement to abolish the requirement of R1.2, and R1.2 is grayed out that it is not currently valid.

  Such a requirement whose type is “change” or “deletion” can be handled in exactly the same way as a normal requirement as described above.

<Embodiment 5>
Next, an example in which the entity of the component revision is linked with the system of the present invention will be described.

  When the component is, for example, a source file or a document file, a general-purpose so-called file version management tool is useful for managing the entity. As such a tool, for example, GNU CVS can be used.

  FIG. 17 shows a configuration in the case where such a file version management tool is used as a back end for component entity management.

  In FIG. 17, a file management server machine A-5 on which the server of the file version management tool operates and a file repository A-6 used by this tool are added to FIG.

  The client program of this file management tool is installed in each client machine A-1, A-2, and each user can use this file management tool directly from his / her client machine.

  Further, the client program of this file management tool is also installed in the server machine A-3 of the system, and the server program can instruct execution to the file management tool and read information by using this.

  Of course, the servers A-3 and A-5 may be the same machine, and there may be a plurality of file management servers or file repositories.

  For linkage, for example, the system stores, as an attribute of the component data B-5, an identifier of the component in the file repository A-5, for example, a repository name and a file path name.

  The component revision name may be the same as the revision name used by the file version management tool, or a revision name correspondence table may be created and managed.

  The system operating procedure is basically the same as S1 to S8 described above, but S4 and S6 are particularly related to the file version management tool.

  When creating a component revision configuration that is the initial state of a new product version in S4, the initial component revision to be used in this product version is first registered in the system database as described above.

  The user may change this data, such as using another revision if necessary.

  If the initial revision of each component is determined to some extent, the system generates a necessary file revision for each component in a batch using a file management tool according to the instructions of the person in charge or the administrator. .

  For example, if a derivative revision needs to be created, the file management tool is instructed to create a branch by specifying the parent revision name.

  When it is necessary to create a revision in which two revisions are merged, two parent revision names are designated to create a merged file revision.

  In S6, the input of the corresponding status for each requirement assigned to the component performed by the person in charge is linked with the file correction work using the file management tool as follows.

  Using the client program of the file management tool, the person in charge first requests the file management server A-5 to check out the file revision to be corrected. This request is first notified to the system program running on the client machine before being executed. This program acquires the revision information to be checked out from the file management server A-5 if necessary, obtains the corresponding component revision information from the system server, and creates a URL for displaying the component revision information. Then, the Web browser is activated to display this URL.

  On this screen, the person in charge assigns a new requirement to this new revision if there is a new requirement for this checkout, and updates the system database. Alternatively, if the requirement is once handled but a problem is found, the response status is changed to “incomplete” and updated.

  The completion of this operation is notified again to the system client program, and the system client program instructs the file management server to actually execute the checkout process by this notification. As a result, the file is checked out from the file management server, and the file is transferred to the client machine.

  Subsequently, the person in charge corrects the file, and requests the server A-5 to check in the file when the correction is completed. In this case as well, the client program of the system traps this request, creates a URL for displaying the component revision information, and activates and displays the Web browser.

The person in charge confirms the requirements assigned to the revision to be checked in on this screen, and changes the corresponding status from “incomplete” to “supported”, for example.
Similarly, the end of this operation is again notified to the system client program, and the system client program instructs the file management server to actually execute the file check-in. As a result, the file on the client machine is transferred to the file management server and stored as a new revision in the file repository.

  As a method for the system to trap a request from the client machine to the file management tool, there is a method of replacing the client program of the file management tool on each client.

  As another method, for example, in GNU and CVS, a file management tool server operating on the file management server A-5 can be set to execute a specified program before and after executing check-in and check-out. is there. In such a case, a system program may be set in the file management server.

It is a figure explaining the basic composition of the present invention. It is a figure explaining the conceptual data structure of this invention. It is a systematic diagram of the product version and component revision for demonstrating as an example. It is a systematic diagram of the product version and component revision for demonstrating as an example. It is a figure explaining the content of each data in this invention. It is a figure explaining the content of each data in this invention. It is a figure explaining the content of each data in this invention. It is a figure explaining the content of each data in this invention. It is a figure explaining the content of each data in this invention. It is a figure explaining the content of each data in this invention. It is a flowchart of the corresponding | compatible status acquisition function of the product version requirement in this invention. It is a figure explaining the example of a screen of the present invention. It is a figure explaining the example of a screen of the present invention. It is a figure explaining the other example of the conceptual data structure in this invention. FIG. 6 is an expanded flowchart of a function status acquisition function for product version requirements according to the present invention. It is a figure explaining the requirement data expanded in this invention. It is a figure explaining the expanded structure of this invention.

Explanation of symbols

A-1 Client A-2 Client A-3 Server A-4 Database (DB)
A-5 File management server A-6 File repository

Claims (5)

  The process of managing the hierarchical structure of a component, the process of assigning requirements to be achieved for its higher components, and the achievement of assigning its requirements to its descendent components to the higher components A process of allocating from among the requirements to be performed, a process of updating the achievement status of the requirements to be achieved assigned to the descendant component as the component revision is updated, and achieving for the upper component based on these processes And a process for calculating the achievement status of power requirements.   2. The project management system according to claim 1, wherein when a defect is found in the achievement status of the requirement assigned to the component, the defect is managed as a new requirement in the same manner as other requirements.   2. The project according to claim 1, wherein when a requirement assigned to the component is deleted or changed, the requirement deletion or requirement change itself is managed as a new requirement in the same manner as other requirements. Management system.   A process of managing a plurality of component revisions based on the component revision at the time of creating the component revision, and estimating a requirement achievement status of the created component revision from a requirement achievement status of the plurality of component revisions. The project management system according to claim 1, further comprising:   2. The project management system according to claim 1, further comprising a file management tool for managing the entity of the component revision, and generating, checking in, and checking out the file revision for the component revision by using the tool.

Images