Patent Application
20090193388
The present application claims priority from Japanese application serial no. 2008-016147, filed on Jan. 28, 2008, the content of which is hereby incorporated by reference into this application.
The present invention relates to a support technique for developing software that is made by collecting respective pieces of design information of design units.
Large scale software development such as development of a enterprise system requires many participants and produces large amounts of deriverables. Thus, person-to-person relationships, deriverable-to-person relationships, and deriverable-to-deriverable relationships become very complex. To contend with this complexity, large scale software development generally employs a development method called the Waterfall Model.
In the Waterfall Model, first a development project is divided into processes or steps. When, design work in a process is finished, fully examined and approved, then design work in the next process is carried out. Further, the project is proceeded in such a way that design work in each process uses design deriverables of the upper processes and delivers the produced deriverables to the lower processes. By doing this, it is possible to clarify a flow of deriverables and make the management of progress easy.
In practice, however, it is rare that all pieces of design information are collected before proceeding to the next process. Further, it is also rare that there is no need to redo an upper process. Three reasons can be mentioned as main reasons for these.
1. Delay becomes too long if downstream work is started after complete collection of upstream deriverables.
2. Particularly in the case of an enterprise system, change of requirements occurs very often, and such change leads to change in specifications.
3. It is unrealistic that design is made without error. Thus, change in specifications can not be avoided to take care of bugs.
Since, as described above, deriverables are large in number and complex, one deriverable relates to many deriverables. Thus, when specifications are to be changed, it is difficult to investigate deriverables related to the specification change and to reveal manually deriverables that are likely to be changed.
As techniques for supporting this work systematically, the techniques described in the following Patent Documents 1 and 2 can be mentioned, for example.
According to the technique described in the Patent Document 1 (Japanese Unexamined Patent Application Laid-Open No. 5-35460), relationships between published deriverables are acquired and managed. When there is a change in some deriverable, information on deriverables that are likely to be changed is provided by notifying the related deriverables to developers, for example by setting the flag on those deriverables.
Further, according to the technique described in the Patent Document 2 (Japanese Unexamined Patent Application Laid-Open No. 2006-79212), common parts of a plurality of published deriverables are extracted and managed in a unified manner. When there is a change in some deriverable, the unifiedly-managed common parts are overwritten to reflect the change automatically and support reflection of the specification change.
The above-described conventional techniques have the following problems.
In each of the techniques described in the Patent Documents 1 and 2, when a specification change occurs and a developer affected by the specification change does not acquire again the design information relating to the specification change, the other developers and the manager will know that fact only after the developer in question registers his deriverables in a repository. Here, the repository means a database used for storing design deriverables in software development. Design deriverables can be published to the other developers by storing the design deriverables in a repository, and then the other developers can freely access the design deriverables.
In large scale development, it is difficult to ensure that a developer's design tool is always coupled with a repository for physical reasons such as dispersion of development bases in a plurality of locations or restriction on use of network. Further, even when a developer is informed of a specification change from the repository by E-mail or the like, the developer frequently wishes to complete design on which he is working now before he deals with the specification change. Thus, sometimes the developer does not immediately take in the changed deriverables to his design tool, and as a result he forgets to deal with the changed deriverables. Further, sometimes upper deriverables held in the design tool may be out of line with the published deriverables for reasons on the side of the developer such as developer's overlooking of a notification itself in the first place. Since the number of developers is large in large scale development, it is highly possible that such a situation occurs.
In such a case, according to the techniques described in the Patent Documents 1 and 2, the necessity of redesign becomes revealed only when a developer examines consistency in pieces of design information (deriverables) after publication of the design information or registration of the design deriverables in the repository. In this case, the following problems occur. (1) The amount of time developers worked without referring to the latest design information goes to waste. (2) The amount of working time of other developers who will be affected by redesign goes to waste. In particular, as regards the problem (2), the larger the scale of development is, the broader the extent of impact becomes. And, the later the necessity of redesign is revealed, the more man-months are used wastefully, causing delay of delivery date.
Thus, an object of the present invention is to improve development efficiency by reducing waste caused by redesign of design information or the like.
To solve the above problems, the present invention is characterized in that:
pieces of design information developed by a developer are stored as respective pieces of public design information into a first storage area of the computer;
the public design information used by a developer for designing design information is acquired from the first storage area, and the acquired public design information is provided as reference design information to the developer;
pieces of public design information used by a developer for designing design information among the pieces of public design information are stored as reference design information into a second storage area of the computer;
when the design information is stored in the first storage area as the public design information, a consistency state between the public design information and reference design information referring to the public design information among the pieces of reference design information stored in the second storage area, and the verified consistency state is stored as a first consistency state into a third storage area of the computer; and
development status information including information of the consistency state stored in the third storage area is notified to an outside.
According to the present invention, when design information is published as public design information, a consistency state between the public design information and reference design information referring to the public design information is verified. This consistency state is notified to a developer or the like even before development design information that has used the reference design information is published. As a result, it is possible to reduce waste owing to redesign or the like of the development design information, and efficiency of the development can be improved.
These and other features, objects and advantages of the present invention will become more apparent from the following description when taken in conjunction with the accompanying drawings wherein:
Now, an embodiment of a software development support apparatus of the present invention will be described referring to the drawings.
As shown in
The software development support apparatus 100 is a computer, and comprises: an input unit 101 such as a keyboard and/or a mouse; an output unit 102 such as a display, a printer or the like; a communication unit 103 for communicating with other apparatuses; an interface 104 for the mentioned component units; a CPU 110 for executing various processing; a memory 105 as a work area for the CPU 110; a storage unit 200 such as a hard disk drive; and a bus 106 coupling these components with one another.
The storage unit 200 comprises: a software development support program 201; a developer design information storage part 202 for storing information that a developer of a software needs at the time of development; a consistency state storage part 203 for storing consistency states of various pieces of information; a public design information storage part 260 for storing, as public design information (deriverables), design information that is produced by a developer and completed for the time being design; a design information status storage part 270 for storing a status of public design information; a related information storage part 280 for storing related information concerning reference between pieces of design information; and a development status storage part 290.
The developer design information storage part 202 stores: reference design information 210 used for designing by a developer; development design information 220 on design that is actually being made by a developer; and developer information 230 for specifying a developer as well as processes and the like whose design is dealt with by that developer. Reference design information 210 is a piece of public design information used as reference design information by a developer, among the public design information stored in the public design information storage part 260. The piece of public design information in question is added with various kinds of management information. Each of the reference design information 210, the development design information 220 and the developer information 230 exists for each developer, and will be described in detail later.
The consistency state storage part 203 stores: storage reference consistency information 240 indicating whether reference design information 210 stored in the developer design information storage part 202 is consistent with public design information; and intra-design-information reference consistency information 250 indicating whether reference design information in development design information (published or unpublished) is consistent with the referred design information (published or unpublished). The storage reference consistency information 240 and the intra-design-information reference consistency information 250 also will be described in detail later.
From the functional viewpoint, the CPU 110 comprises: a request input part 111 that receives various requests from developers; a design information input part 112 that receives design information; a design information output part 113 that outputs design information; a design information relation acquisition part 114 that acquires related information between pieces of design information; a reference design information recording part 115 that stores reference design information 210 into the developer design information storage part 202, wherein the reference design information 210 is some of the pieces of public information stored in the public information storage part 260; a design information publication part 116 that stores public design information into the public design information storage part 260, wherein the public design information is pieces of design information whose publication has been requested among the pieces of design information received by the design information input part 112; a status management part 117 that manages statuses of the public design information stored in the public information storage part 260; a storage reference consistency verification part 118a that verifies whether the reference design information 210 stored in the developer design information storage part 202 is consistent with the public design information; an intra-design-information reference consistency verification part 118b that verifies whether the reference design information in the development design information (published or unpublished) is consistent with the referred design information (published or unpublished); a development status generation part 119a that generates development status information; and a development status notification part 119b that notifies a requester of the development status information. Here, each of these functional parts 111-119b functions when the CPU 110 executes the software development support program 201.
Next, referring to the conceptual diagram shown in
Here, it is assumed that “satoh” is in charge of an “interface definition” process, and he designs an interface definition “getCustomerInfoListByName” by using public design information “CustomerNo” 261a of “yamada” in the public design information storage part 260 as reference design information. Further, it is assumed that “kimura” is in charge of an “image view definition” process, and he designs an image view definition “CustomerInfoImageView” by using public design information “getCustomerInfoListByName” 261b of “satoh” in the public design information storage part 260 as reference design information. That is to say, here, the design information “CustomerNo” of “yamada” is the uppermost design information, and the design information “getCustomerInfoListByName” of “satoh” is its lower design information, and the design information “CustomerInfoImageView” of “kimura” is the lowermost design information.
First, in response to a request from the developer “satoh”, the software development support apparatus 100 provides the public design information “CustomerNo” 261a of “yamada” in the public design information storage part 260 as reference design information to the developer “satoh”. Here, the public design information “CustomerNo” 261a is to be used for designing the interface definition “getCustomerInfoListByName”. Further, the software development support apparatus 100 stores the public design information “CustomerNo” 261a as reference design information 210 into the developer design information storage part 202 (S5).
The developer “satoh” designs the interface definition “getCustomerInfoListByName” by using the reference design information “Customer No” provided from the software development support apparatus 100. When the software development support apparatus 100 receives a request for saving the interface definition “getCustomerInfoListByName” from the developer “satoh”, the software development support apparatus 100 saves the definition in the developer design information storage part 202 as development design information (S11).
After that, when the software development support apparatus 100 receives a request for publishing the interface definition “getCustomerInfoListByName” from the developer “satoh”, the software development support apparatus 100 verifies consistency information stored in the consistency state storage part 203 (S16). When the consistency information is “consistent”, the software development support apparatus 100 publishes the design information in question as public design information 261b (S17). In other words, the software development support apparatus 100 stores the interface definition “getCustomerInfoListByName” as the public design information 261b in the public design information storage part 260 so that other developers can use it.
Also in the case where the developer “kimura” designs the image view definition “CustomerInfoImageView”, the software development support apparatus 100 stores the public design information “getCustomerInfoListByName” 261b as reference design information 210 into the developer design information storage part 202 similarly to the above (S5). And, the software development support apparatus 100 saves the image view definition “CustomerInfoImageView” designed by using this in the developer design information storage part 202 as development design information 220 (S11). Further, when the software development support apparatus 100 receives a request for publishing the image view definition “CustomerInfoImageView” from the developer “kimura”, the software development support apparatus 100 verifies consistency information (S16), and thereafter publishes the design information in question as public design information 261c (S17).
In passing, in actual software development, the public design information “CustomerNo” 261a of “yamada”, which is referred to by the developer “satoh”, is often changed to “CustomerID” before or after the developer “satoh” publishes the interface definition “getCustomerInfoListByName”. Change of the uppermost design information “CustomerNo” affects not only the lower design information “getCustomerInfoListByName” of “satoh” but also the much lower design information “CustomerInfoImageView” of “kimura”.
As described in the Background of the Invention, there may occur a situation where the reference design information held in a developer terminal is out of line with the public design information stored in the public design information storage part 260 because of restriction of the network, the main subject of the developer himself, or the like. In such a case, according to the techniques of the Patent Documents 1 and 2, it will be revealed only after publication of the design information that inconsistency lies in the design information and redesign is needed. This causes a problem such that revelation of the need for redesign is delayed.
In the present embodiment, the design information “getCustomerInfoListByName” that is referred to by the developer “kimura” is not only provided to the developer “kimura”, but also stored as the reference design information 210 in the developer design information storage part 202. The development design information “CustomerInfoImageView” is designed by using the reference design information in question. When the upper development design information (i.e. the development design information “getCustomerInfoListByName” as the origin of the reference design information) to the development design information “CustomerInfoImageView” is published as the public design information 261b (S17) even if the development design information “CustomerInfoImageView” is not published, then consistency is verified between the public design information 261b and the reference design information “getCustomerInfoListByName” 210 of the development design information that refers to the public design information 261b (S19). The verified consistency state is notified to the developer “kimura” and others.
Further, in the present embodiment, when the design information “getCustomerInfoListByName” is saved as the development design information 220 in the developer design information storage part 202 (S11), the consistency state is verified between the reference design information “CustomerNo” included in the development design information “getCustomerInfoListByName” and “CustomerNo” stored as the reference design information 210 in the developer design information storage part 202 (S13), and this consistency state is notified to the developers. Further, in the present embodiment, when the development design information “getCustomerInfoListByName” is modified and thereafter published as the public design information 261b again (S17), and if the design information “CustomerInfoImageView 261c” that refers to the public design information 261b in question is already published, then consistency between the newly-published public design information “getCustomerInfoListByName” 261b and the reference design information “getCustomerInfoListByName” included in the already-published lower-side public design information “CustomerInfoImageView” 261c is verified (S21), and this consistency state also is notified to the developers.
Next, referring to the flowcharts shown in
As shown in
The step 2 is a process in which the request input part 111 judges whether the request from the developer or the manager is a request to acquire design information. If it is a request to acquire design information, the flow proceeds to the step 3. Otherwise, the flow proceeds to the step 10 (
Then, the steps 3-9 are processes responding to the design information acquisition request, and executed by the functional parts 111, 113, 115, 117 and 118a shown in
The step 3 is a process in which the request input part 111 judges the classification of the design information acquisition request. If the classification of the design information acquisition request is a request to acquire reference design information that is referred to at the time of design, the flow proceeds to the step 4. On the other hand, if the classification of the design information acquisition request is a request to acquire development design information of design that is to be started now, then the flow proceeds to the step 7.
The steps 4-6 described in the following are processes responding to the request to acquire reference design information.
The step 4 is a process in which the design information output part 113 provides the reference design information to the developer. Based on the developer information 230, the design information output part 113 takes out a list of public design information referred to by the developer from the public design information storage part 260. Then, the design information output part 113 outputs the acquired public design information as reference design information to the developer terminal D or the output unit 102.
Here, as shown in
The public design information storage part 260 is a database in which design information that is produced by a developer and completed for the time being is stored as public design information (deriverable). Thus, the public design information storage part 260 is a repository. As shown in
Further, in the present embodiment, design information means a smallest design unit, which will not make sense if it is divided. Thus, design information is one record of information in
For example, if the developer having the identifier “satoh” requests acquisition of reference design information in this step 4, the design information output part 113 refers to the developer information 230 (
The step 5 is a process in which the reference design information storage part 115 stores reference design information into the developer design information storage part 202. The reference design information storage part 115 acquires the public design information that the design information output part 113 provides to the developer in the step 4, and stores the acquired public design information as the reference design information 210 of the developer in question into the developer design information storage part 202.
As shown in
For example, if the public design information 261a (
The step 6 is a process in which the storage reference consistency verification part 118a records the consistency state of the reference design information stored in the step 5. Here, the newest reference design information has just been provided to the developer, and thus the state “consistent” is recorded as the consistency state of the reference design information in relation to the public design information that is the origin of the reference design information.
As shown in
With that, the processing of acquiring the reference design information is ended, and the flow returns to the step 1.
In the present embodiment, the reference design information provided to the developer in the step 3 is saved in the step 5. By this arrangement, it is possible to detect early a possibility of occurrence of inconsistency in the reference design information or the design information produced by using the reference design information, before the developer publishes the design information produced by using the reference design information. As a result, it becomes possible to notify the newest consistency state to the developer or the manager before publication of the design information. Also, it becomes possible to provide a progress status of the developer in detail. Details of a method of notifying the progress status will be described later.
As described above, if it is judged in the step 3 that the classification of the design information acquisition request is a request to acquire development design information, the flow proceeds to the step 7. The steps 7-9 described in the following are processes responding to a request to acquire development design information.
The step 7 is a process in which the status management part 117 refers to the design information status storage part 270 to verify the status of development design information. As shown in
The step 8 is a process in which the design information output part 113 provides the development (public) design information. The design information output part 113 takes out the design information requested by the developer from the public design information storage part 260, and outputs the acquired public design information as development design information to the developer terminal D or the output unit 102. At that time, the design information output part 113 may examine whether the developer is trying to acquire development design information as for design information of a process that is not in his charge.
The step 9 is a process in which the status management part 117 updates the status of the public design information. Since the public design information was provided as the development design information to the developer in the step 8, the status management part 117 writes into the design information status storage part 270 the fact that the public design information has been in the check-out state so that the public design information is treated as the design information in the course of editing.
The step 9 finishes the processing concerning the request to acquire the development design information, and the flow returns to the step 1.
As described above, if it is judged in the step 2 that the request from the developer or the manager is not a request to acquire design information, the flow proceeds to the step 10 (
In the flowchart of
The step 10 is a process in which the request input part 111 judges whether the request from the developer or the manager is a request for saving development design information or not. If it is a request for saving development design information, the flow proceeds to the step 11. Otherwise, the flow proceeds to the step 15.
The steps 11-14 described in the following are processes responding to the request for saving the development design information.
The step 11 is a process in which the design information input part 112 saves the development design information received from the developer or the like. The design information input part 112 receives the development design information from the developer terminal D through the communication unit 103 and the request input 111, and saves the received information as the development design information 220 of the developer in question into the developer design information storage part 202. In some cases, the development design information is received from the developer or the like through the input unit 101.
As shown in
The step 12 is a process in which the design information relation acquisition part 114 acquires related information. When the design information input part 112 saves the development design information 220 in the step 11, the design information input part 112 calls the design information relation acquisition part 114. The design information relation acquisition part 114 acquires a relation of data of each item in the development design information 220 saved in the step 11 to reference design information of the development design information 220, and writes the acquired relation in the related information storage part 280. That is to say, the design information relation acquisition part 114 grasps what piece of reference design information is used in which part of the development design information, and writes it in the related information storage part 280.
As shown in
For example, among the related information 281 of
The step 13 is a process in which the intra-information reference consistency verification part 118b verifies whether the reference design information in the development design information is consistent with the referred design information. That is to say, here, it is verified whether the reference design information in the development design information saved in the step 11 has been changed while the development design information is being edited and whether the development design information is consistent with the new reference design information. The intra-information reference consistency verification part 118b refers to the related information 281 written in the related information storage part 280 in the step 12 and acquires the reference design information indicated by the related information 281 from the developer design information storage part 202. Then, the intra-information reference consistency verification part 118b compares the acquired reference design information with the item data (reference design information) in the development design information indicated by the related information 281, to verify the consistency between them.
The step 14 is a process in which the intra-information reference consistency verification part 118b records the state of intra-information consistency verified in the step 13 in the consistency state storage part 203.
As shown in
With that, the processing in response to the request for saving the development design information is ended, and the flow returns to the step 1.
As described above, if it is judged in the step 10 that the request from the developer or the manager is not a request for saving development design information, the flow proceeds to the step 15.
The step 15 is a process in which the request input part 111 judges whether the request from the developer or the manager is a request for publishing development design information. If it is a request for publishing development design information, the flow proceeds to the step 16. Otherwise, the flow proceeds to the step 23 (
The steps 16-22 described in the following are processes responding to the request for publishing development design information.
The step 16 is a process of verifying the storage reference consistency information 240 and intra-information reference consistency information 250 relating to the development design information in question.
The storage reference consistency verification part 118a refers to the related information 281 stored in the related information storage part 280 and acquires the identifier of the reference design information used for the development design information whose publication is requested by the developer in order to confirm the storage reference consistency information 240 of the reference design information having that identifier. For example, in the case where the object of the publication request is the interface definition “getCustomerInfoListByName” shown in
The intra-information reference consistency verification part 118b acquires identifiers (i.e. item identifiers) of the reference design information used for the development design information whose publication is requested by the developer, from the development design information in question, and verifies the intra-information reference consistency information 250 of the reference design information of these identifiers. For example, the intra-information reference consistency verification part 118b acquires the item identifiers “IFOUT-0104”, “IFOUT-0105”, . . . of the development design information “getCustomerInfoListByName”, and verifies all pieces of intra-information reference consistency information 250 (
If all pieces of storage reference consistency information 240 corresponding to the development design information indicate “consistent” and all pieces of intra-information reference consistency information indicate “consistent”, then the flow proceeds to publication processing in the step 17. Otherwise, publication of the development design information in question is rejected.
The step 17 is a process in which the design information publication part 116 publishes the development design information, or in other words stores the development design information in question as public design information into the public design information storage part 260. For example, as shown in
The step 18 is a process in which the status management part 117 updates the status of the development design information. The design information publication part 116 writes in the design information status storage part 270 to the effect that the development design information is stored as public design information in the public design information storage part 260 and as a result the public design information is in the check-in state.
The step 19 is a process in which, as shown in
Now, the processing by the storage reference consistency verification part 118a in the step 19 will be described in detail by using the flowcharts shown in
The step 31 is a process of verifying a classification of publication of the published development design information. If the publication classification is addition of the development design information, the flow proceeds to the step 32. Or, if the publication classification is update of the development design information, the flow proceeds to the step 35. And, if the publication classification is deletion of the development design information, the flow proceeds to the step 41 (
The step 32 is a process of extracting a developer referring to the development design information whose publication classification is addition. The storage reference consistency verification part 118a refers to the developer information 230 (
The step 33 is a process of determining that the reference design information of the developer extracted in the step 32 is “unreferenced added item inconsistent”. The developer referring to the development design information whose publication classification is “addition” has not yet acquired the development design information in question. Forgetting of acquisition causes omission of design/development concerning newly-published or -added development design information. Thus, it is determined that the design information in question is “unreferenced added item inconsistent”.
For example, in the case where the developer “yamada” of the data item acquires a list of public design information of the data items, adds a data item “ItemPrice” as shown in the changed list of public design information as shown in
The step 34 is a process of judging whether there is a developer who has not been extracted yet by the extraction process of the step 32. If there is a developer who has not been extracted yet, the flow returns to the step 32 to extract a developer. Otherwise, the processing is ended.
As described above, if it is judged in the step 31 that the publication classification of the development design information is “update”, the flow proceeds to the step 35.
The step 35 is a process of extracting reference design information whose identifier coincides with that of the development design information in question out of the list of reference design information. The storage reference consistency verification part 118a acquires the list of reference design information from the developer design information storage part 202, and extracts reference design information whose identifier coincides with that of the published development design information in question.
The step 36 is a process of judging whether the management information of the published development design information coincides with that of the extracted reference design information. If both pieces of management information coincide with each other, the flow proceeds to the step 39. Otherwise, the flow proceeds to the step 37.
The step 37 is a process of judging whether the development design main body information of the published development design information coincides with that of the extracted reference design information. If corresponding pieces of item data of both pieces of design main body information coincide with each other, the flow proceeds to the step 39. If data of any item of both pieces of design main body information do not coincide, the flow proceeds to the step 38.
The step 38 is a process of determining that the reference design information of the developer extracted in the step 35 is “updated item reference inconsistent”. Further, the step 39 is a process of determining that the reference design information of the developer extracted in the step 35 is “consistent”. When the processing of the step 38 or 39 is ended, the flow proceeds to the step 40.
For example, it is assumed that the data item developer “yamada” acquires the list of public design information before change shown in
The step 40 is a process of judging whether there is reference design information that has not been extracted yet. If there is reference design information that has not been extracted, the flow returns to the step 35 to extract reference design information further more. If there is not reference design information that has not been extracted yet, the processing is ended.
As described above, if it is judged in the step 31 that the publication classification of the development design information is “deletion”, the flow proceeds to the step 41 (
The step 41 is a process of extracting reference design information that coincides with the development design information in question out of the list of reference design information. The storage reference consistency verification part 118a acquires the list of reference design information from the developer design information storage part 202, and extracts reference design information whose identifier coincides with that of the development design information whose deletion has been published.
The step 42 is a process of determining that the reference design information in question is “deleted item reference inconsistent”. If a developer continues to refer to deleted public design information, it is possible that the deleted information is erroneously embedded in development design information, causing reduction in quality of the design. Thus, it is determined that the reference design information in question is “deleted item reference inconsistent”.
The step 43 is a process of judging whether there is reference design information that has not been extracted yet. If there is reference design information that has not been extracted yet, the flow returns to the step 41 to extract reference design information furthermore. If there is not reference design information that has not been extracted, the processing is ended.
For example, it is assumed that the data item developer “yamada” acquires the list of public design information before change shown in
Thus, the processes of the steps 31-43 bring an end to the processing (the step 19) of verifying consistency with stored reference design information of the other developers in the flowchart of
The step 20 is a process in which the storage reference consistency verification part 118a updates the storage reference consistency information 240 in the consistency state storage part 203 on the basis of the verification result of the consistency verification processing of the step 19.
As described above referring to
As shown in
For example, it is assumed that the interface developer “satoh” has published the interface “getCustomerInfoListByName” (the identifier “IF-0014”) as development design information. In this case, the intra-information reference consistency verification part 118b first extracts related information 281 whose reference design information identifier 283 is the identifier “IF-0014” of the newly-published development design information from the related information storage par 280 (
The step 22 is a process in which the intra-information reference consistency verification part 118b updates the intra-information reference consistency information 250 in the consistency state storage part 203 on the basis of the verification result of the consistency verification processing of the step 21.
Thus, the processes of the steps 15-22 bring an end to the processing in response to the request for publication of development design information, and the flow returns to the step 1.
As described above, if it is judged in the step 15 (
The step 23 is a process in which the request input part 111 judges whether the request from the developer or the manager is a report request or not. If the request is a report request, the flow proceeds to the step 24. Otherwise, the flow returns to the step 1. The steps 24-26 described in the following are processes responding to the report request.
The step 24 is a process in which the request input part 111 judges the classification of the report requester. If the report requester is the manager, the flow proceeds to the step 25. If the requester is a developer, the flow proceeds to the step 26.
The step 25 is a process of providing a development status report. The development status generation part 119a generates a development status information, writes the generated development status information into a development status storage part 130, and calls the development status notification part 119b. The development status notification part 119b acquires the development status information generated by the development status generation part 119a from the development status storage part 130, and notifies the acquired development status information to the manager as the requester. Here, the development status generation part 119a generates development status information when a request for a development status occurs. However, it is possible that the development status generation part 119a generates development status information periodically.
The development status information includes: reference consistency information classified by developer, which is obtained by aggregating the storage reference consistency information 240 for each developer; reference consistency information classified by development process, which is obtained by aggregating the storage reference consistency information 240 for each development process; and estimated progress status information classified by development process. These kinds of consistency information are each given in a table form. The development status notification part 119b may notify the manager of only one kind of information that has been requested by the manager among these three kinds of information, or may notify the manager of all three kinds of information.
As shown in
In addition to the above fields, the reference consistency information classified by developer 290a has an inconsistent design information detail 299a for showing explicitly a kind of inconsistency for each piece of design information, and other data.
The development status generation part 119a generates the reference consistency information classified by developer 290a by referring to the storage reference consistency information 240 (
The manager grasps developers who are in a reference inconsistent state on the basis of the reference consistency state information classified by developer 290a, and urges those developers to acquire the newest information. When the manager wishes to know the inconsistent reference design information in detail, the manager requests the inconsistent design information detail 299a and inspects it.
As shown in
The development status generation part 119a generates the reference consistency information classified by development process 290b by referring to the statuses stored in the design information status storage part 270 as well as the storage reference consistency information 240 (
As described referring to
As described above, the development status notification part 119b acquires the reference consistency information classified by development process 290b generated by the development status generation part 119a from the development status storage part 130, and notifies the acquired information to the manager as the requester.
Based on the reference consistency information classified by development process 290b, the manager can know whether each piece of design information is under working or has been published and who is the developer in charge, and whether the reference design information of the developer is consistent if under working.
As shown in
Thus, in generating the estimated progress status classified by development process 290c, the development status generation part 119a refers also to the intra-information reference consistency information 250 (
The estimated progress status field 296c stores “treating change”, “treated change”, “need to treat change”, “non-starting to treat change”, or the like. Since the estimated progress status of each piece of design information is notified to the manager, the manager can grasp the progress status of the development more accurately.
Here, a method of obtaining an estimated progress status of each piece of design information will be described.
First, the development status generation part 119a acquires the storage reference consistency information 240 (
When the development status generation part 119a acquires the treatment status for each item data (reference design information) in each piece of design information, then the development status generation part 119a acquires the estimated progress status of each piece of design information according to the flowchart shown in
In detail, the development status generation part 119a examines the status concerning the design information in question (S51). If the status of the design information is “check-in”, the flow proceeds to the step 52. Or, if the status of the design information is “check-out”, the flow proceeds to the step 55. In the step 52, it is judged whether an inconsistent data item exists among the data items in the design information. If there is an inconsistent data item, the estimated progress status is determined as “need to change” in the step 53 to indicate that change is needed with respect to the design information. Further, if there is no inconsistent data item, the estimated progress status is determined as “no need to change” in the step 54 to indicate that change is not necessary with respect to the design information.
In the case where the status of the design information is judged in the step 51 to be “check-out” and the flow proceeds to the step 55, it is judged whether all data items of the design information have been already “treated”. If all data items of the design information have been already “treated”, the status is determined as “treated change” in the step 56 to indicate change has been treated with respect to the design information. Further, if not all data items of the design information have been already “treated”, the flow proceeds to the step 57.
In the step 57, it is judged whether the status is “change has not been treated” with respect to all data items of the design information. If the status is “change has not been treated” with respect to all data items, the status is determined as “non-starting to treat change” in the step 58 to indicate that treatment of change concerning the design information in question has not been started. If it is not true that the status is “change has not been treated” with respect to all data items of the design information, the flow proceeds to the step 59.
In the step 59, it is judged whether, for each of all data items of the design information, the status is either “treated” or “change has not been treated”. If the status of each data item is either “treated” or “change has not been treated”, the status is determined as “treating change” in the step 60. If it is not true that each data item is either “treated” or “change has not been treated”, the flow proceeds to the step 61.
In the step 61, it is judged whether there is a data item in the status “caution needed” among all data items of the design information. If there is a data item in the status “caution needed”, the estimated progress status is determined as “marked developer” in the step 62 to indicate that attention should be paid to this developer since the developer has not made any change. If no data item is in the status “caution needed”, the estimated progress status is determined as “reference information requiring update” in the step 63 considering that the design information in question includes the status “reference to old version”.
The development status generation part 119a stores the result of status judgment of the step 53, 54, 56, 58, 60, 62 or 63 into the estimated progress status field 296c of the estimated progress status classified by development process 290c.
With that, the processing of obtaining the estimated progress status of each piece of design information is ended.
Here, the estimated progress status is obtained for each development process. However, it is possible to obtain an estimated progress status for each developer, and provide it to the manager.
As described above, if it is judged in the step 24 (
The step 26 is a process of providing a consistency state report concerning all pieces of design information included in the process in charge of the developer who has made the report request. The consistency state report is generated by the development status generation part 119a and notified by the development status notification part 117 to the developer as the requester.
This consistency state report indicates the storage reference consistency state and the intra-information reference consistency state with respect to all pieces of design information included in the process in charge of the developer who has made the report request, by referring to the storage reference consistency information 240 and the intra-information reference consistency information 250.
As a method of displaying the consistency state report, it is possible to consider, for example: (1) a method of using a dialogue to display occurrence of inconsistency on a screen; (2) a method of displaying on a screen a list of design information in which inconsistency exists; (3) a method of displaying design information in which inconsistency exists in a different color on a design screen; and (4) a method of adding hyperlink or a button to design information in which inconsistency exists on a design screen, where for example a click of information causes displaying of detailed contents of the inconsistency or candidates for change.
Thus, the processes of the steps 23-26 bring an end to the processing of the report request, and the flow returns to the step 1.
Thus, the present embodiment can reveal possibility that inconsistency between already-published deriverables may cause problems, when a software developer is preparing design without referring to the newest deriverables in the stage before publishing design information to the public design information storage part 260, and can notify it to the developer and other persons. Further, according to the present embodiment, it is possible to detect reference inconsistency for each data item in development information of a developer, and reject inappropriate publishing of the design information caused by developer's alteration or forgetting of update. As a result, the embodiment of the present invention can reduce waste owing to redesign of design information or the like, and promote the efficiency of development.
Further, according to the embodiment of the present invention, it is also possible to notify the manager of progress information that indicates how many developers have acquired and dealt with newly-published or -corrected design information. Thus, the manager can easily perform process management of the software development.
While we have shown and described several embodiments in accordance with out invention, it should be understood that the disclosed embodiments are susceptible of changes and modifications without departing from the scope of the invention. Therefore, we do not intend to be bound by the details shown and described herein but intend to cover all such changes and modifications within the ambit of the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2008-016147 | Jan 2008 | JP | national |
