Software maintenance status management device

Abstract

The objective of the present disclosure is to assist understanding of the status of maintenance of large-scale software performed by a plurality of persons. A software maintenance status management device (101) comprises: a source code acquisition unit (12) that acquires a source code of software; a software structure analysis unit (13) that analyzes the source code to create software structure information in which the software is divided into a plurality of sections; a software change information input unit (15) to which software change information including at least information on the details of a change to the software, a changed section, and the person who made the change is input; a software structure reflection unit (16) that reflects the change in the source code to the software structure information on the basis of the software change information; and a proficiency calculation unit (17) that calculates, for each section, proficiency in the software of each of a plurality of persons in charge of a maintenance task of the software, on the basis of the software change information and the software structure information.

Description

[Technical Field]

[0001] The present disclosure relates to a technique for managing the maintenance status of large-scale software. [Background technology]

[0002] In recent years, as software has become larger and more complex, the number of maintenance tasks required to accommodate customer requests for additional functions or specification changes has increased.

[0003] In order to carry out software maintenance work, it is necessary to understand the design and implementation of the existing software, as well as to understand in advance the development implementation rules, such as development regulations or coding conventions, which outline the development procedures.

[0004] Patent document 1 proposes a work distribution support device that manages in a database the timing, duration, language used, type of development, and worker evaluation results of software development that workers have previously been responsible for, calculates the reliability of each worker regarding the content of maintenance work, and supports the optimal distribution of work. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent No. 6609414 Summary of the Invention [Problem to be solved by the invention]

[0006] In recent years, the scale of software development, such as the number of folders, files, and lines of code that need to be changed during software maintenance work, has increased, and it has become common for software maintenance work to be shared among multiple people. In this case, while it is possible for a single person to gain a deep understanding of the specifications and implementation of the software portion of the work, such as the function that they are responsible for, it is difficult for them to understand the specifications and implementation of the software as a whole.

[0007] In Patent Document 1, the details of development are managed in a database, with each software development carried out in the past treated as a single unit. Therefore, in large-scale software development in which multiple people share the design and implementation responsibilities, a part or function that a person in charge has not been responsible for before may be assigned to that person, and that person may have to investigate the specifications of that part or function from scratch.

[0008] The technology disclosed herein has been made in consideration of the above-mentioned problems, and aims to support understanding of the maintenance status of large-scale software carried out by multiple people. [Means for solving the problem]

[0009] The software maintenance status management device disclosed herein comprises a source code acquisition unit that acquires the source code of the software, a software structure analysis unit that creates software structure information that divides the software into multiple parts by analyzing the source code, a software change information input unit to which software change information including at least information on the software changes, the changed parts, and the person who made the changes is input, a software structure reflection unit that reflects the changes to the source code in the software structure information based on the software change information, and a proficiency calculation unit that calculates the software proficiency for each part for each of multiple staff members in charge of software maintenance work based on the software change information and the software structure information. [Effects of the Invention]

[0010] The software maintenance status management device disclosed herein can calculate the software proficiency level of each person in charge of software maintenance work for each part of the software. Therefore, it is possible to support understanding the maintenance status of large-scale software carried out by multiple people. Objects, features, aspects, and advantages of the present disclosure will become more apparent from the following detailed description and the accompanying drawings. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a block diagram showing a configuration of a software maintenance status management device according to a first embodiment. [Figure 2] FIG. 10 is a diagram showing the parts of the software that have been changed by a person in charge. [Figure 3] FIG. 10 is a diagram showing a first proficiency level of each person in charge calculated by a first calculation method. [Figure 4] FIG. 2 is a diagram showing the number of lines of each software function. [Figure 5] FIG. 10 is a diagram showing the number of lines changed for each function by each person in charge. [Figure 6] FIG. 10 is a diagram showing a first proficiency level of each person in charge calculated by a second calculation method. [Figure 7] FIG. 10 is a diagram showing the source code changes made by person A and the source code changes made by person B in function Func. [Figure 8] FIG. 10 is a block diagram showing the configuration of a software maintenance status management device according to a second embodiment. [Figure 9] FIG. 1 is a software structure diagram showing the relationships between functions. [Figure 10] FIG. 10 is a diagram showing the first proficiency level of person in charge A when person in charge A changes function B. [Figure 11] 10 is a diagram showing the first proficiency level and the second proficiency level of person in charge A when person in charge A changes function B. FIG. [Figure 12] FIG. 11 is a block diagram showing the configuration of a software maintenance status management device according to a third embodiment. [Figure 13] FIG. 1 is a diagram showing a traceability matrix. [Figure 14] FIG. 10 is a block diagram showing the configuration of a software maintenance status management device according to a fourth embodiment. [Figure 15] FIG. 11 is a block diagram showing the configuration of a software maintenance status management device according to a fifth embodiment. [Figure 16] FIG. 10 is a diagram showing the proficiency level of each function of each person in a matrix. [Figure 17] FIG. 1 is a software structure diagram showing the relationships between functions. [Figure 18]It is a diagram showing an example display of maintenance information representing the proficiency of person in charge C. [Figure 19] It is a diagram showing an example display of maintenance information representing the proficiency of person in charge D. [Figure 20] It is a diagram showing an example display of maintenance information representing the proficiency of persons in charge C and D. [Figure 21] It is a block diagram showing the configuration of the software maintenance status management device according to Embodiment 6. [Figure 22] It is a diagram showing defect information. [Figure 23] It is a diagram showing the proficiency before update. [Figure 24] It is a diagram showing the calculation of proficiency based on defect information. [Figure 25] It is a diagram showing the proficiency after update based on defect information. [Figure 26] It is a block diagram showing the configuration of the software maintenance status management device according to Embodiment 7. [Figure 27] It is a diagram showing an example of the hierarchical relationship of workers in the development system. [Figure 28] It is a diagram showing development system information. [Figure 29] It is a diagram showing the proficiency before update. [Figure 30] It is a diagram showing the calculation of proficiency based on development system information. [Figure 31] It is a diagram showing the proficiency after update based on development system information. [Figure 32] It is a hardware configuration diagram of the software maintenance status management device. [Figure 33] It is a hardware configuration diagram of the software maintenance status management device.

Embodiments for Carrying Out the Invention

[0012] <A. Embodiment 1> 1 is a block diagram showing the configuration of a software maintenance status management device 101 according to embodiment 1. The software maintenance status management device 101 includes a source code acquisition unit 12, a software structure analysis unit 13, a software structure recording unit 14, a software change information input unit 15, a software structure reflection unit 16, a proficiency calculation unit 17, and a proficiency recording unit 18.

[0013] The source code acquisition unit 12 acquires the source code 11 implemented using various programming languages. The source code acquisition unit 12 may acquire the source code 11 from outside the software maintenance status management device 101.

[0014] The software structure analysis unit 13 analyzes the software structure from the source code 11 acquired by the source code acquisition unit 12, and stores software structure information, which is information on the analyzed software structure, in the software structure recording unit .

[0015] Generally, software is composed of variables that maintain internal states or calculation results, and functions that describe the processing order. As an example, the software structure analysis unit 13 is realized by application software executed on a personal computer (hereinafter referred to as PC). The software structure analysis unit 13 analyzes the static structure of the software from the source code 11. The static structure of the software includes the types of variables or functions, processing sequences such as branches or loops implemented in functions, which functions are called from which other functions, which variables are referenced in which functions, etc.

[0016] The software structure recording unit 14 is generally a recording medium such as a hard disk drive (HDD) or a solid state drive (SDD).

[0017] When software is changed, software change information, which is information about the software change, is input to software change information input unit 15. The software change information includes the software change content, the change date, and information about the person who made the change. Software change information input unit 15 is generally implemented using a version control tool such as Apache Subversion or Git. A typical version control tool has a function that, when the source code is changed, notifies relevant parties of the source code change in cooperation with tools such as email.

[0018] When software change information is input to the software change information input unit 15, the software structure reflecting unit 16 determines whether the software related to the software change information, i.e., the changed software, is a maintenance target. If the changed software is a maintenance target, the software structure reflecting unit 16 provides the software change information to the software structure analyzing unit 13 and instructs it to reanalyze the software structure of the changed software.

[0019] Upon receiving this instruction, the software structure analysis unit 13 analyzes the latest software structure based on the software change information obtained from the software structure reflection unit 16, and updates the software structure information in the software structure recording unit 14 to the latest information.

[0020] The proficiency calculation unit 17 calculates the proficiency of the person in charge of the software change based on the software change information input to the software change information input unit 15 and the software structure information stored in the software structure recording unit 14, and stores the calculation result in the proficiency recording unit 18.

[0021] Figure 2 shows software maintained by multiple people. Generally, software consists of multiple functions. In Figure 2, software 51 consists of six functions A, B, C, D, E, and F. Also, person A changes function A, person B changes functions B, D, and E, and person C changes functions C, E, and F.

[0022] In this embodiment, the proficiency calculation unit 17 calculates the proficiency of each person in the implementation portion of the source code that has been changed as the first proficiency.

[0023] A first calculation method for the first proficiency level will be described with reference to Figures 2 and 3. In the first calculation method, the calculation formula for the first proficiency level P1 for each function of each person in charge is expressed as P1 = k1 × (presence or absence of function change). k1 is a constant. (presence or absence of function change) is 1 if the function has been changed and 0 if it has not.

[0024] If k1=100, the calculation results of the first proficiency level will be as shown in Figure 3. Personnel A's first proficiency level will be "+100" for function A. Personnel B's first proficiency level will be "+100" for functions B, D, and E. Personnel C's first proficiency level will be "+100" for functions C, E, and F.

[0025] The proficiency calculation unit 17 calculates the first proficiency P1 for each changed function as described above each time the software is changed, and calculates the first proficiency of each person in charge for each function of the software by accumulating the calculated first proficiency P1. The calculation unit of the first proficiency is determined according to the use or purpose of the calculation, and may be the above-mentioned function unit, or the function unit, file unit, or folder unit that constitutes the function. Furthermore, the proficiency calculation unit 17 may group multiple functions together and calculate the first proficiency for each grouped function.

[0026] Next, the second calculation method for the first proficiency level will be explained with reference to Figures 4, 5, and 6. The second calculation method takes into account the scale of the function. Generally, the implementation scale of the functions that make up software, i.e., the number of lines of source code that realize the function, varies depending on the content of the requirements that the function fulfills or the complexity of the processing logic. Hereinafter, the number of lines of source code that realize a function will be simply referred to as the number of lines of the function.

[0027] FIG. 4 shows the number of lines of each function of the software 51 in FIG. 2. FIG. 5 shows the number of lines of changes made by each person in charge of each function of the software 51. FIG. 6 shows the calculation results of the first proficiency level for the examples of FIGS. 4 and 5. In the second calculation method, the calculation formula for the first proficiency level P1 is expressed as P1 = k1 × (number of changed lines / total number of lines in the function to which the changes belong). If k1 = 100, then the first proficiency level of person A for function A is expressed as P1 = 100 × (100 / 2000) = +5.

[0028] The first calculation method of first proficiency explained in Figure 3 does not take into account differences in the scale of each function, so a single first proficiency level is calculated regardless of the number of lines of the function or the number of lines changed. However, the second calculation method makes it possible to calculate a first proficiency level according to the number of lines changed by each person in charge. For example, looking at the calculation results of the first proficiency level for function E in Figure 6, the first proficiency level of person B, who changed 100 lines, is +3.3, while the first proficiency level of person C, who changed 2,000 lines, is +66.7. In this way, the larger the number of lines changed, the higher the first proficiency level.

[0029] Next, a third calculation method for the first proficiency level will be described with reference to Figure 7. In this third calculation method, software changes made by one person affect the first proficiency levels of other people. Figure 7 shows that after person A makes a modification to a function Func that implements a certain function, person B makes a further modification.

[0030] Assume that person A implemented the top 1800 lines of the source code of function Func. That is, the top 1800 lines of Func are person A's source code changes 61. Note that in this specification, writing new source code is also referred to as "changing source code" in addition to changing existing source code. Thereafter, person B changes the last 200 lines of person A's source code changes 61, and then adds and implements 600 new lines. That is, person B's source code changes 62 consist of 200 lines that overlap with person A's source code changes 61 and another 600 lines. In this case, person B's first proficiency level P1 is calculated as follows, similar to the second calculation method: P1 = k1 × (number of changed lines / total number of lines in the function to which the changes belong) = k1 × (200 lines + 600 lines) / 2400 lines = k1 × 0.333. If k1=100, the first proficiency level P1 of person in charge B becomes +33.3. In other words, the first proficiency level P1 of person in charge B increases by 33.3.

[0031] On the other hand, the source code change portion 61 of person A is reduced by 200 lines due to the source code change by person B. Therefore, person A's first proficiency P1 is calculated as follows: P1 = -k2 x (number of lines of the person's own source code change due to the source code change by another person / number of lines of function) = -k2 x 200 / 2400 = -k2 x 0.083. If k2 = 100, person A's first proficiency P1 will decrease by 8.3. Here, the constant k2 when the first proficiency decreases due to the source code change by another person may be the same value as the constant k1 when the first proficiency increases. Alternatively, taking into consideration that person A is already familiar with the specifications of function Func, k2 can be set so that the decrease in the first proficiency is small. <k1であってもよい。

[0032] Furthermore, when most of the source code change portion 61 of person in charge A has been changed by the source code change by person in charge B, the proficiency calculation unit 17 may determine that most of the specifications of function Func that person in charge A knows have been changed, and may significantly reduce the first proficiency of person in charge A. Therefore, the proficiency calculation unit 17 may change the value of k2 according to the proportion of the number of lines that are further changed by the source code change by another person in the source code change portion of each person in charge.

[0033] Next, we will explain the fourth calculation method for the first proficiency level. The fourth calculation method takes into account the time elapsed since the software was modified. If a long time has passed since the software was modified, each person in charge may forget the specifications of the software's functions related to the modified part. Therefore, in the fourth calculation method, the first proficiency level is set to be smaller the longer the time elapsed since the software was modified. In the fourth calculation method, for example, the calculation formula for the first proficiency level P1 is expressed as P1=P'-iD. Here, P' is the first proficiency level P1 calculated by any of the above first to third calculation methods. i is a constant. D is the time elapsed since the software was modified.

[0034] As described above, the software maintenance status management device 101 according to the first embodiment includes a source code acquisition unit 12, a software structure analysis unit 13, a software change information input unit 15, a software structure reflection unit 16, and a proficiency calculation unit 17. The source code acquisition unit 12 acquires the source code of the software. The software structure analysis unit 13 analyzes the source code to create software structure information that divides the software into multiple parts. The software change information input unit 15 receives software change information that includes at least information on the changes to the software, the changed parts, and the person who made the changes. The software structure reflection unit 16 reflects the changes to the source code in the software structure information based on the software change information. The proficiency calculation unit 17 calculates the software proficiency for each part of the software for each of the multiple people in charge of software maintenance work based on the software change information and the software structure information.

[0035] With the above configuration, according to the software maintenance status management device 101, by using the structure information of the software, the proficiency of each person in charge with respect to the software can be calculated for each part such as functions. Therefore, in the maintenance of large-scale software implemented by a plurality of persons in charge sharing the work, it becomes possible to specify an optimal person in charge based on the proficiency for each part of the software.

[0036] <B. Embodiment 2> FIG. 8 is a block diagram showing the configuration of a software maintenance status management device 102 according to Embodiment 2. The software maintenance status management device 102 includes an influence range extraction unit 19 in addition to the configuration of the software maintenance status management device 101 according to Embodiment 1. The influence range extraction unit 19 extracts other parts of the software affected by a change as a change influence range when a certain part of the software is changed.

[0037] Software is generally composed of function calls, variable references, and variable writes. When a part of the source code is changed, the influence of the change does not remain only in the changed part. For example, when an arithmetic expression written to a variable is modified, it is conceivable that a part that performs branch determination by referring to the same variable may perform a different branch process than before. Also, when the processing procedure within a function is changed, the argument values of the functions called from within that function may change, and the processing within the called function may change.

[0038] Generally, a software changer investigates and analyzes the change influence range before changing the software, and determines whether the influence reaching the change influence range conforms to the design intention. As a result, the software changer becomes familiar not only with the specifications of the part of the source code that he / she actually changes, but also with the specifications of the change influence range.

[0039] Therefore, the proficiency calculation unit 17 in embodiment 2 not only calculates the first proficiency based on the software change information in the same manner as in embodiment 1, but also calculates the second proficiency, which is the proficiency of each person in relation to the change impact range, using the change impact range extracted by the impact range extraction unit 19.

[0040] An example of calculating the second proficiency level will be described with reference to the software structure diagram in Figure 9. In Figure 9, the relationships between the functions that make up the software 51, i.e., the influences between them, are represented by arrows. For example, an arrow connects function A to function B. This indicates that function A is related to function B, and that function B is used to realize function A. In other words, changing the processing of function A affects function B, and conversely, changing the processing of function B affects function A. Functions B and C are not connected by an arrow. In other words, changing function B does not affect function C.

[0041] Here, we will show an example of calculating proficiency when person in charge A changes function B. According to the first calculation method described in the first embodiment, person in charge A's first proficiency P1 for function B is calculated by P1 = k1 × (whether or not the function has been changed), and when k1 = 100, it is +100 as shown in FIG.

[0042] Next, consider calculating the second proficiency level for the scope of change impact. The formula for calculating the second proficiency level P2 is P2 = e × (impact or no impact), where e is a constant. (impact or no impact) is 1 if there is an impact and 0 if there is no impact. The functions affected by a change to function B, i.e., the scope of impact of the change to function B, are function A, which uses function B, and functions D and E, which function B uses. If the second proficiency levels for functions A, D, and E are listed together with the first proficiency levels in Figure 10, person A's proficiency levels for each function are as shown in Figure 11. Person A's second proficiency levels for functions A, D, and E are each +50. Here, we assume that person A's specification understanding of functions A, D, and E is lower than his specification understanding of function B, which he actually changed, and set e = 50 < 100 = k1.

[0043] The proficiency calculation unit 17 may change the constant e in the second proficiency calculation formula according to the type and degree of "relationship" between functions. For example, in case 1 where the relationship between functions A and B consists only of "function calls", the modifier of function A can understand the specification change of function B due to the change of function A by investigating the specifications of the interfaces of the functions of A and B. On the other hand, in case 2 where the relationship between functions A and B consists of a plurality of "variable references and writes" within functions A and B, in order to grasp the specification change of function B due to the change of function A, it is necessary to investigate how the variables are used in the processing. That is, in case 2, it is necessary to investigate the specifications of the affected range deeper than in case 1. Therefore, in the case of case 2, the constant e may be made larger than in case 1 so that the second proficiency increases more significantly.

[0044] Also, in the software configuration diagram of FIG. 9, when person A in charge changes function D, among function B that is directly affected by the change of function D and function A that is affected by the change of function D via function B, it is considered that person A has a greater understanding of the specifications of function B. Therefore, the constant e used in the calculation of the second proficiency of these functions may be changed so that the second proficiency of function B of person A in charge is greater than the second proficiency of function A.

[0045] As described above, the software maintenance status management device 102 according to Embodiment 2 includes an affected range extraction unit 19 in addition to the configuration of the software maintenance status management device 101 according to Embodiment 1. The affected range extraction unit 19 extracts, as the change affected range, parts other than the changed parts of the software that are affected by the change of the software based on the software structure information. Thereby, according to the software maintenance status management device 102, not only the parts of the software actually changed by each person in charge but also the proficiency can be calculated assuming that the person in charge is familiar with the specifications of the other change affected ranges.

[0046] <C. Embodiment 3> 12 is a block diagram showing the configuration of software maintenance status management device 103 according to embodiment 3. Software maintenance status management device 103 includes specification change information input unit 20 and trace information input unit 21 in addition to the configuration of software maintenance status management device 102 according to embodiment 2. Note that software maintenance status management device 103 may also include specification change information input unit 20 and trace information input unit 21 in addition to the configuration of software maintenance status management device 101 according to embodiment 1.

[0047] Specification change information relating to changes to specifications, which are the deliverables of software development, is input to the specification change information input unit 20. The specification change information includes at least information on the part of the specification that was changed and the person who made the change, and may further include information such as the date and time of the change.

[0048] The trace information input unit 21 receives trace information indicating the correspondence between the description of the specification and the implementation location of the source code.

[0049] In general, in software development, design work is performed to determine the software's processing content, functional interfaces, and other details before the implementation work of creating source code, and specifications are created as the result of the design work. When software is modified, the changes to be made and the scope of impact of the changes are analyzed before the source code is changed, and the results are recorded in a specification. In large-scale software development, it is common for different people to be responsible for software design and implementation. When the changes to the source code related to functional design cover a wide range of areas, there are cases where one person performs the design work, and multiple people share the work of implementing (modifying) the source code based on the changes. In this case, the software maintenance status management devices 101 and 102 according to the first and second embodiments can calculate the proficiency level of the person who modified the source code, but cannot calculate the proficiency level of the person involved in the design of the function.

[0050] In contrast, the software maintenance status management device 103 of this embodiment regards the proficiency level of each function of the person in charge of software design work, i.e., the person who made the changes to the specifications, as the third proficiency level, and calculates it using the following procedure. Here, changes to the specifications include not only changes to the descriptions in the existing specifications, but also the addition of new descriptions to the specifications.

[0051] When the specification is changed, the specification change information is input to the specification change information input unit 20. As with source code, specifications can also be managed using a general version control tool. As with the software change information input unit 15, the specification change information input unit 20 is also realized by a general version control tool. This version control tool automatically detects that the specification has been changed.

[0052] When specification change information is input to the specification change information input unit 20, the proficiency calculation unit 17 identifies the implementation part corresponding to the changed specification based on the specification change information and the trace information input from the trace information input unit 21, and then calculates the proficiency of that implementation part.

[0053] Generally, the format of specifications varies depending on the software development. For example, there are cases where specifications are separated for each software function, and the correspondence between the specifications and the implemented source code is clear. In such cases, the proficiency calculation unit 17 can easily identify the implementation part of the corresponding source code from the specification change information, so the trace information input unit 21 is not necessary.

[0054] In cases where the correspondence between the contents of the specification and the implemented source code is unclear, the proficiency calculation unit 17 utilizes trace information in which the two have been previously associated. As an example of trace information, a traceability matrix is ​​shown in FIG. 13. The vertical axis of this traceability matrix indicates the location of the specification, such as a chapter, section, or paragraph, and the horizontal axis indicates the implementation location (in this example, function). When there is a relationship between the specification location and the function, a "circle" is added at the intersection of the vertical and horizontal axes. For example, the content described in specification "1.2 XXX" relates to functions B, C, and D, and the content described in specification "1.4 XXX" relates to functions E and F. The proficiency calculation unit 17 refers to such trace information to identify the implementation location corresponding to the changed specification.

[0055] Then, the proficiency calculation unit 17 calculates a third proficiency, which is the proficiency of the person who made the change to the specifications for the implementation part corresponding to the change to the specifications. For example, the calculation formula for the third proficiency P3 of each person for each function is expressed as P3 = k3 × (presence or absence of relationship to the changed specifications). For example, in the example of FIG. 13, if person A changes specification "1.2 XXX", and k3 = 100, person A's third proficiency P3 for functions B, C, and D becomes "+100". Then, every time the specifications are changed, the proficiency calculation unit 17 calculates the person's third proficiency for each function in the software by adding the third proficiency P3 obtained as described above.

[0056] The above method is an application of the first calculation method for the first proficiency level described in the first embodiment to the calculation of the third proficiency level.

[0057] Furthermore, the proficiency calculation unit 17 may calculate the third proficiency P3 by P3 = k3 × (number of changed lines in the specification / total number of lines in the description location in the specification to which the changed part belongs). This method is an application of the second calculation method for the first proficiency described in the first embodiment to the calculation of the third proficiency.

[0058] Similarly, the third calculation method or the fourth calculation method of the first proficiency level described in Embodiment 1 may be applied to the calculation of the third proficiency level.

[0059] According to the software maintenance status management device 103 of Embodiment 3, not only the proficiency level of the implementer of each function of the software (the first proficiency level or the second proficiency level), but also the proficiency level of the designer who is proficient in the specifications of each function (the third proficiency level) can be calculated.

[0060] As described above, the software maintenance status management device 103 according to Embodiment 3 includes a specification change information input unit 20 in addition to the configurations of the software maintenance status management devices 101 and 102 according to Embodiments 1 and 2. Specification change information including at least the change part of the software specification and the information of the changer is input to the specification change information input unit 20. The proficiency calculation unit 17 identifies the software part corresponding to the change part of the specification included in the specification change information, and calculates the proficiency based on the identified software part. Therefore, according to the software maintenance status management device 103, the proficiency level of the person in charge who changed the specification with respect to the software part corresponding to the specification change part can be calculated.

[0061] <D. Embodiment 4> FIG. 14 is a block diagram showing the configuration of a software maintenance status management device 104 according to Embodiment 4. The software maintenance status management device 104 includes a review information input unit 22 in addition to the configuration of the software maintenance status management device 103 according to Embodiment 3. Note that the software maintenance status management device 104 may include a review information input unit 22 in addition to the configuration of any one of the software maintenance status management devices 101 and 102 according to Embodiments 1 and 2.

[0062] Review information regarding software reviews is input to the review information input unit 22. The review information input unit 22 outputs the input review information to the proficiency calculation unit 17. The review information includes at least information on the part of the software to be reviewed, the reviewer, and the content of the review, and may further include information on the date and time of the review.

[0063] The proficiency calculation unit 17 calculates the reviewer's proficiency with the part being reviewed as a fourth proficiency, based on the review information acquired from the review information input unit 22. The proficiency calculation unit 17 calculates the fourth proficiency in addition to the first proficiency described in the first embodiment, the second proficiency described in the second embodiment, and the third proficiency described in the third embodiment.

[0064] Generally, reviews are conducted by a third party other than the designer or implementer who is familiar with the software specifications. A review is a process in which design defects are pointed out in the design document, which is the product of the design work, and implementation errors are pointed out in the source code, which is the product of the implementation work. A review of the design document is called a design review, and a review of the source code is called a source code review.

[0065] Software reviews include not only minor findings such as typographical errors in specifications, but also important findings such as implementation defects that require a redesign or the identification of impacts that the designers have not considered. Such important findings cannot be made without a thorough understanding of the specifications of the target function, so it can be said that the reviewer who made the findings is sufficiently familiar with the specifications of the target function.

[0066] We will explain how to calculate the fourth proficiency level. The simplest formula for calculating the fourth proficiency level P4 is P4 = k4 × (number of comments), where k4 is a constant. According to the above formula, the proficiency level of a reviewer who makes many comments will increase.

[0067] The proficiency calculation unit 17 may calculate the fourth proficiency P4 in consideration of the pointed-out content of the review. Generally, a method of ranking review results according to the importance of the pointed-out content is known. For example, a pointed-out for a minor event such as a misdescription in a specification is ranked as "A", a pointed-out for an error in a partial processing procedure that requires a review only for the corresponding part is ranked as "B", and a pointed-out for a contradiction related to most of the design that requires a review of the previous design is ranked as "C". For the pointed-out of "C", it is necessary to fully understand the specification of the target function, while for the pointed-out of "A", it can be done just by looking at the target part, that is, it can be done without fully understanding the specification of the target function. From this perspective, the proficiency calculation unit 17 assigns weights according to the importance of the pointed-out content to the number of pointed-out items. Specifically, the calculation formula for the fourth proficiency P4 is P4 = k A × (the number of pointed-out of "A") + k B × (the number of pointed-out of "B") + k C × (the number of pointed-out of "C"). Here, k A , k B , k C are constants, and k A < k B < k C . Thus, it becomes possible to calculate the fourth proficiency according to the importance of the pointed-out content.

[0068] As described above, the software maintenance status management device 104 according to Embodiment 4 includes a review information input unit 22 in addition to the configurations of the software maintenance status management devices 101, 102, and 103 according to Embodiments 1, 2, and 3. Review information regarding the review of the software is input to the review information input unit 22. The review information includes at least information on the part of the software to be reviewed, the reviewer, and the content of the review. The proficiency calculation unit 17 calculates the proficiency based on the review information. Therefore, according to the software maintenance status management device 104, it is possible to calculate the proficiency with respect to each function of the software not only for the software designer or implementer but also for the reviewer who is in charge of the review.

[0069] <E. Embodiment 5> 15 is a block diagram showing the configuration of software maintenance status management device 105 according to embodiment 5. Software maintenance status management device 105 includes a maintenance status display control unit 23 in addition to the configuration of software maintenance status management device 104 according to embodiment 4. Note that software maintenance status management device 105 may include a review information input unit 22 in addition to the configuration of any one of software maintenance status management devices 101, 102, and 103 according to embodiments 1, 2, and 3.

[0070] The maintenance status display control unit 23 creates maintenance information that indicates the maintenance status of each function of the software based on the software structure information stored in the software structure recording unit 14 and the proficiency information stored in the proficiency recording unit 18. Then, the maintenance status display control unit 23 causes the display device 31 to display the maintenance information.

[0071] Display device 31 is, for example, an organic EL (electroluminescence) display or a liquid crystal display. In Fig. 15, display device 31 is provided outside software maintenance status management device 105, but software maintenance status management device 105 and display device 31 may be configured integrally.

[0072] The maintenance status display control unit 23 determines the maintenance status from the proficiency calculated by the proficiency calculation unit 17. For example, if there is no person in charge who is highly proficient with a certain function, it means that maintenance work for that function cannot be performed. Conversely, if there are multiple people in charge who are highly proficient with a certain function, it means that maintenance work for that function can be performed sufficiently.

[0073] Figure 16 shows in a matrix the proficiency levels for each function of personnel A, B, C, and D involved in the software development. Personnel A's proficiency level for function A is 1000. Personnel B's proficiency level for each of functions B, C, D, E, and F is 20. Figure 16 shows that multiple personnel are familiar with the specifications of functions B, C, D, E, and F. Furthermore, it can be seen that only person A is familiar with the specifications of function A, and that if person A is absent, maintenance work for function A cannot be carried out. Furthermore, while person B is familiar with the specifications of functions B, C, D, E, and F, his proficiency level for each of these functions is low, and it can be seen that maintenance work cannot be entrusted to him alone.

[0074] Figure 17 is a software structure diagram in tree format similar to Figure 9. Each function that makes up the software is represented by a rectangle, and the relationships between functions are represented by arrows. For example, function A is related to function B, and function B is used to realize function A.

[0075] 18 to 20 show examples of displaying maintenance information on the display device 31. In Fig. 18 to 20, the proficiency of each person in charge shown in Fig. 16 is superimposed on the software structure diagram of Fig. 17. Fig. 18 shows the proficiency of person C shown in Fig. 16 superimposed on the software structure diagram of Fig. 17, indicating the maintenance status of each function by person C. Similarly, Fig. 19 shows the proficiency of person D shown in Fig. 16 superimposed on the software structure diagram of Fig. 17, indicating the maintenance status of each function by person D.

[0076] In the display example of Fig. 18, functions C, E, and F, whose specifications person in charge C is familiar with, are hatched to distinguish them from functions A, B, and D, whose specifications person in charge C is not familiar with. This allows a user such as a software developer who sees this display example to get an overview of the parts of the entire software that person in charge C can maintain.

[0077] In the display example of FIG. 19, functions B, D, and F, in which person D is proficient in the specifications, are hatched and displayed separately from functions A, C, and E in which person D is not proficient in the specifications. Further, different hatchings are applied to the functions according to the proficiency level of person D. Here, low-density linen hatchings are applied to functions with a proficiency level of 50 or more and less than 200, high-density linen hatchings are applied to functions with a proficiency level of 200 or more and less than 1500, and solid black hatchings are applied to functions with a proficiency level of 1500 or more.

[0078] In FIG. 19, functions with different proficiency levels are distinguished by hatchings, but they may also be distinguished by colors. For example, functions with a higher proficiency level may be displayed in a darker color. Thus, a user such as a software development manager who views this display example can visually grasp the detailed maintenance status.

[0079] FIG. 20 shows the result of adding the proficiency levels of person C and person D superimposed on a software structure diagram.

[0080] According to the software maintenance status management device 105 according to Embodiment 5, since the software structure and the proficiency level for each function of each person in charge are superimposed and displayed, it is possible to visually grasp the maintenance information for each function (each part) of the software.

[0081] As described above, in addition to the configurations of the software maintenance status management devices 101, 102, 103, and 104 according to Embodiments 1, 2, 3, and 4, the software maintenance status management device 105 according to Embodiment 5 includes a maintenance status display control unit 23. The maintenance status display control unit 23 causes the display device 31 to display the maintenance information in which the calculation result of the proficiency level by the proficiency level calculation unit 17 is superimposed on the software structure information. Therefore, according to the software maintenance status management device 105, a user such as a software development manager can easily grasp the proficiency level of each person in charge for each part of the software.

[0082] <F. Embodiment 6> 21 is a block diagram showing a configuration of a software maintenance status management device 106 according to embodiment 6. The software maintenance status management device 106 is obtained by adding a defect information input unit 24 to the software maintenance status management device 105 according to embodiment 5.

[0083] The defect information input unit 24 receives defect information.

[0084] Before a defect can be fixed, tasks that are thought to increase proficiency are carried out, such as checking various specifications, interviewing the person in charge of the related module, and using a debugger to investigate the cause. Here, defect information refers to the location (module) where the defect occurs in the software, the amount of work required to fix it, and the person in charge of the fix. The location where the defect occurs is part of the software structure shown above. The amount of work required to fix it is the amount of work required from investigating the cause of the defect to correcting it. Identifying the cause of the defect also includes the time required for interviews and verifying operation.

[0085] FIG. 22 shows an example of defect information. Each line in FIG. 22 shows one piece of defect information. That is, FIG. 22 shows a total of four pieces of defect information. The defect information includes information on the defect number, the location of the defect, the amount of work required to fix it, and the person in charge of fixing it. Here, the unit of work required to fix it is hours.

[0086] The proficiency calculation unit 17 refers to the defect information input to the defect information input unit 24 and calculates the proficiency separately from the amount of change in the source code. If the calculated proficiency is P, the proficiency before the update is P', and a constant is d, the proficiency P calculated from the defect information is expressed as P = P' + d × (defect correction man-hours), where d > 0.

[0087] Examples of proficiency calculations using the defect information in FIG. 22 are shown in FIGS. 23 to 25. FIG. 23 shows the proficiency before the defect information is input, indicating the proficiency of functions A, B, C, and D for person in charge A, person in charge B, and person in charge C. Here, when the constant d in the proficiency calculation formula based on the defect information is set to 5, the proficiency added due to the defect information is as shown in FIG. 24.

[0088] That is, for person in charge A, the proficiency added to function A is 5 (constant) × 10 (Hr) = 50, and the proficiency added to function D is 5 (constant) × 8 (Hr) = 40. For person in charge B, the proficiency added to function C is 5 (constant) × 20 (Hr) = 100. For person in charge C, the proficiency added to function A is 5 (constant) × 5 (Hr) = 25. The above proficiencies are added to the proficiency before the update shown in FIG. 23, and the proficiency shown in FIG. 25 is obtained.

[0089] The proficiency calculation formula shown here is an example. As other methods for updating proficiency using defect information, it is conceivable to consider the proficiency before the update and the discovery process of the defect as coefficients. Since defects may span multiple modules as they are discovered in subsequent processes and the cause investigation may become difficult, the coefficient may increase as the subsequent process progresses.

[0090] In this embodiment, by using defect information in the calculation of proficiency, it is possible to consider the improvement in proficiency due to defect correction, which is a proficiency that cannot be obtained from the amount of source code changes, and more accurate proficiency presentation becomes possible.

[0091] <G. Embodiment 7> FIG. 26 is a block diagram showing the configuration of the software maintenance status management device 107 according to Embodiment 7. The software maintenance status management device 107 is obtained by adding a development system information input unit 25 to the software maintenance status management device 106 according to Embodiment 6.

[0092] Development system information is input to the development system information input unit 25.

[0093] In large-scale projects, teams are divided into specific software modules, and each team is responsible for a specific module. Workers within a team may have a hierarchical relationship, such as between a leader and members. In some cases, the leader will collectively commit all of the members' source code changes to the repository of the source code control system, in which case the source code control system will not record any changes made by the members. In other cases, the leader may share the information and knowledge he or she has gained with the members, thereby improving the team's proficiency. Here, development organization information refers to information that shows the hierarchical relationships between workers, as shown above.

[0094] Figure 27 shows an example of the hierarchical relationships among workers in a development system. Here, two teams are shown: one with person A as the leader, and the other with person E as the leader. As shown, person A has members B, C, and D. Person E has members F and G, and person F has member H.

[0095] The development organization information for this development organization can be shown as in Figure 28. In this example, information such as who the leader of each person is is shown in table format. In this example, the leader refers to one person, but it is also possible to refer to multiple people. When the proficiency of a leader is updated, it is likely that the proficiency of the members of that leader will also be updated. Therefore, when the proficiency of a person is updated, the development organization information in Figure 28 is referenced, and the proficiency of the members (who have the person whose proficiency has been updated as their leader) is also updated. It is unlikely that the proficiency of a member will be greater than that of the person whose proficiency has been directly updated. Therefore, if the calculated proficiency is P, the proficiency before the update is P', and the constant is s, the proficiency P calculated by referencing the development organization information is expressed as P = P' + s × (additional proficiency of the leader). However, if 0 <s<1である。

[0096] Figures 29 to 31 show how the overall proficiency level is updated when the proficiency levels of the leaders, Worker A and Worker E, are updated when the development organization information in Figure 28 is used. Figure 29 shows the proficiency level of each member before the update. This shows an example of a software development project with functions A, B, C, D, E, and F, where development is being carried out using the development organization shown in Figure 27.

[0097] Here, as shown in FIG. 30, assume that the leader, person in charge A, has had a proficiency increase of +40 in function B, and person in charge E has had a proficiency increase of +40 in function E. Using the proficiency calculation formula described above, the proficiency of person A or the person who has person in charge E as their leader is updated. If the constant s is 0.25, the proficiency increase for function B of persons B, C, and D who have person in charge A as their leader is 0.25 (constant) × 40 (addition for person A) = 10. Similarly, the proficiency increase for function E of persons F and G who have person in charge E as their leader is 0.25 (constant) × 40 (addition for person E) = 10. Furthermore, person H has person in charge F as his leader, and since person in charge F's proficiency has been updated, the proficiency increase for function E is 0.25 (constant) × 10 (addition for person F) = 2.5.

[0098] The addition calculated as above is added to the proficiency level before update shown in FIG. 29, and the proficiency level shown in FIG. 31 is obtained.

[0099] In this example, the proficiency level is updated in the same way when the leader's leader is updated, but it is also possible to not update the proficiency level unless it is the direct leader, or to decrease the constant s each time the level of command between the leader and the members increases. Also, by making the value of constant s variable depending on the leader, it is possible to take into account the degree of influence the leader has on the proficiency level of the members, or the degree of growth as a team.

[0100] By using development organization information to calculate proficiency as in this embodiment, it is possible to accurately calculate and present the proficiency of each person in a large-scale project managed by multiple teams.

[0101] <H. Hardware Configuration> In the software maintenance status management devices 101-107 described above, the source code acquisition unit 12, software structure analysis unit 13, software structure recording unit 14, software change information input unit 15, software structure reflection unit 16, proficiency calculation unit 17, proficiency recording unit 18, influence range extraction unit 19, specification change information input unit 20, trace information input unit 21, review information input unit 22, maintenance status display control unit 23, defect information input unit 24, and development system information input unit 25 are realized by the processing circuit 81 shown in FIG. 32. That is, the processing circuit 81 includes the source code acquisition unit 12, software structure analysis unit 13, software structure recording unit 14, software change information input unit 15, software structure reflection unit 16, proficiency calculation unit 17, proficiency recording unit 18, influence range extraction unit 19, specification change information input unit 20, trace information input unit 21, review information input unit 22, maintenance status display control unit 23, defect information input unit 24, and development system information input unit 25 (hereinafter, the source code acquisition unit 12, etc.). For the processing circuit 81, dedicated hardware may be applied, or a processor that executes a program stored in a memory may be applied. The processor is, for example, a central processing unit, processing device, arithmetic device, microprocessor, microcomputer, DSP (Digital Signal Processor), etc.

[0102] When the processing circuit 81 is dedicated hardware, the processing circuit 81 corresponds to, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a combination thereof. The functions of each part such as the source code acquisition unit 12 may be realized by a plurality of processing circuits 81, or the functions of each part may be realized by one processing circuit collectively.

[0103] When the processing circuit 81 is a processor, the functions of the source code acquisition unit 12 and the like are realized by a combination of software, etc. (software, firmware, or software and firmware). The software, etc. is written as a program and stored in memory. As shown in FIG. 33, the processor 82 applied to the processing circuit 81 realizes the functions of each unit by reading and executing a program stored in the memory 83. That is, the software maintenance status management device 101-105 includes a memory 83 for storing a program that, when executed by the processing circuit 81, results in the processing of the source code acquisition unit 12 and the like. It can also be said that this program causes a computer to execute the procedure or method of the source code acquisition unit 12 and the like. Here, the memory 83 may be, for example, a non-volatile or volatile semiconductor memory such as RAM (Random Access Memory), ROM (Read Only Memory), flash memory, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), HDD (Hard Disk Drive), magnetic disk, flexible disk, optical disk, compact disk, mini disk, DVD (Digital Versatile Disk) and its drive device, or any storage medium to be used in the future.

[0104] The above describes a configuration in which each function of the source code acquisition unit 12, etc. is realized either by hardware or software, etc. However, the present invention is not limited to this, and a configuration in which part of the source code acquisition unit 12, etc. is realized by dedicated hardware and another part is realized by software, etc. For example, the function of the proficiency calculation unit 17 can be realized by a processing circuit as dedicated hardware, and the other functions can be realized by the processing circuit 81 as the processor 82 reading and executing programs stored in the memory 83.

[0105] As described above, the processing circuit can realize each of the above-mentioned functions by hardware, software, or a combination of these. Note that the software structure recording unit 14 and the proficiency recording unit 18 are configured from memory 83, but they may be configured from a single memory 83 or each may be configured from a separate memory.

[0106] The above describes preferred embodiments in detail, but the present invention is not limited to the above embodiments, and various modifications and substitutions can be made to the above embodiments without departing from the scope of the claims.

[0107] Various aspects of the present disclosure are summarized below as appendices.

[0108] (Appendix 1) a source code acquisition unit that acquires the source code of the software; a software structure analysis unit that analyzes the source code to create software structure information in which the software is divided into a plurality of parts; a software change information input section into which software change information including at least information on the change content, the change portion, and the person who made the change is input; a software structure reflecting unit that reflects the change in the source code in the software structure information based on the software change information; a proficiency calculation unit that calculates a proficiency level of the software for each of the parts for each of a plurality of personnel in charge of maintenance work of the software based on the software change information and the software structure information, Software maintenance status management device.

[0109] (Appendix 2) the proficiency calculation unit calculates the proficiency based on whether or not each of the persons in charge has made a change to each part of the software. 2. The software maintenance status management device according to claim 1.

[0110] (Appendix 3) the proficiency calculation unit calculates the proficiency based on the ratio of the number of changed lines in each part of the software by each of the persons in charge to the total number of lines in each part. 3. The software maintenance status management device according to claim 1 or 2.

[0111] (Appendix 4) When at least a part of the changes made to each part of the software by each of the persons in charge is later further changed by another of the persons in charge, the proficiency calculation unit reduces the proficiency of each of the persons in charge in accordance with the proportion of the parts further changed by the other person in charge among the changes made to each part of the software by each of the persons in charge. 4. A software maintenance status management device according to any one of claims 1 to 3.

[0112] (Appendix 5) the proficiency calculation unit reduces the proficiency of each of the personnel in accordance with the elapsed time since the software change by each of the personnel. 5. A software maintenance status management device according to any one of claims 1 to 4.

[0113] (Appendix 6) an impact extent extraction unit that extracts, based on the software structure information, a portion of the software other than the changed portion that is affected by the change of the software as a change impact extent; The proficiency calculation unit calculates the proficiency based on the change influence range as well. 6. A software maintenance status management device according to any one of claims 1 to 5.

[0114] (Appendix 7) a specification change information input unit into which specification change information including at least information on a change portion and a changer of the software specification is input; the proficiency calculation unit identifies a part of the software corresponding to a changed part of the specification included in the specification change information, and calculates the proficiency based on the identified part of the software. 7. A software maintenance status management device according to any one of claims 1 to 6.

[0115] (Appendix 8) a trace information input unit to which trace information that associates parts of the specification with parts of the software is input; the proficiency calculation unit identifies a part of the software corresponding to a changed part of the specification based on the specification change information and the trace information; 8. The software maintenance status management device according to claim 7.

[0116] (Appendix 9) a review information input unit for inputting review information about reviews of the software; the review information includes at least information on a portion of the software to be reviewed, a reviewer, and a review content; the proficiency calculation unit calculates the proficiency based on the review information. 9. A software maintenance status management device according to any one of Supplementary Note 1 to Supplementary Note 8.

[0117] (Appendix 10) a maintenance status display control unit that displays, on a display device, maintenance information in which the calculation result of the proficiency level by the proficiency level calculation unit is superimposed on the software structure information, 10. The software maintenance status management device according to any one of Supplementary Note 1 to Supplementary Note 9.

[0118] (Appendix 11) a defect information input unit into which defect information relating to a defect in the software is input, The proficiency calculation unit calculates the proficiency based on the defect information as well. 11. A software maintenance status management device according to any one of claims 1 to 10.

[0119] (Appendix 12) a development system information input unit into which development system information relating to the software development system is input, the proficiency calculation unit calculates the proficiency based on the development system information as well. 12. A software maintenance status management device according to any one of claims 1 to 11. [Explanation of symbols]

[0120] 11 source code, 12 source code acquisition unit, 13 software structure analysis unit, 14 software structure recording unit, 15 software change information input unit, 16 software structure reflection unit, 17 proficiency calculation unit, 18 proficiency recording unit, 19 impact scope extraction unit, 20 specification change information input unit, 21 trace information input unit, 22 review information input unit, 23 maintenance status display control unit, 24 defect information input unit, 25 development organization information input unit, 31 display device, 51 software, 81 processing circuit, 82 processor, 83 memory, 101-105 software maintenance status management device.

Claims

1. a source code acquisition unit that acquires the source code of the software; a software structure analysis unit that analyzes the source code to create software structure information in which the software is divided into a plurality of parts; a software change information input section into which software change information including at least information on the change content, the change portion, and the person who made the change is input; a software structure reflecting unit that reflects the change in the source code in the software structure information based on the software change information; a proficiency calculation unit that calculates a proficiency level of the software for each of the parts for each of a plurality of personnel in charge of maintenance work of the software based on the software change information and the software structure information, Software maintenance status management device.

2. the proficiency calculation unit calculates the proficiency based on whether or not each of the persons in charge has made a change to each part of the software.

2. The software maintenance status management device according to claim 1.

3. the proficiency calculation unit calculates the proficiency based on the ratio of the number of changed lines in each part of the software by each of the persons in charge to the total number of lines in each part.

3. The software maintenance status management device according to claim 1.

4. When at least a part of the changes made to each part of the software by each of the persons in charge is later further changed by another of the persons in charge, the proficiency calculation unit reduces the proficiency of each of the persons in charge in accordance with the proportion of the parts further changed by the other person in charge among the changes made to each part of the software by each of the persons in charge.

2. The software maintenance status management device according to claim 1.

5. the proficiency calculation unit reduces the proficiency of each of the personnel in accordance with the elapsed time since the software change by each of the personnel.

2. The software maintenance status management device according to claim 1.

6. an impact extent extraction unit that extracts, based on the software structure information, a portion of the software other than the changed portion that is affected by the change of the software as a change impact extent; The proficiency calculation unit calculates the proficiency based on the change influence range as well.

2. The software maintenance status management device according to claim 1.

7. a specification change information input unit into which specification change information including at least information on a change portion and a changer of the software specification is input; the proficiency calculation unit identifies a part of the software corresponding to a changed part of the specification included in the specification change information, and calculates the proficiency based on the identified part of the software.

2. The software maintenance status management device according to claim 1.

8. a trace information input unit to which trace information that associates parts of the specification with parts of the software is input; the proficiency calculation unit identifies a part of the software corresponding to a changed part of the specification based on the specification change information and the trace information; The software maintenance status management device according to claim 7.

9. a review information input unit for inputting review information about reviews of the software; the review information includes at least information on a portion of the software to be reviewed, a reviewer, and a review content; the proficiency calculation unit calculates the proficiency based on the review information.

2. The software maintenance status management device according to claim 1.

10. a maintenance status display control unit that displays, on a display device, maintenance information in which the calculation result of the proficiency level by the proficiency level calculation unit is superimposed on the software structure information, 2. The software maintenance status management device according to claim 1.

11. a defect information input unit into which defect information relating to a defect in the software is input, The proficiency calculation unit calculates the proficiency based on the defect information as well.

2. The software maintenance status management device according to claim 1.

12. a development system information input unit into which development system information relating to the software development system is input, the proficiency calculation unit calculates the proficiency based on the development system information as well.

2. The software maintenance status management device according to claim 1.

Images