NL9002460A - METHOD FOR ANALYZING AND FORECASTING A PROGRAM DEVELOPMENT PROCESS - Google Patents

Description

Method for analyzing and predicting a program development process.

The invention relates to a method for analyzing a computer-aided software development process, according to which method at least once during the process one or more parameters of the product under development are determined and compared with previously determined in the production process corresponding parameters in order to gain insight into the development process and the resulting product.

Software development has various phases, such as problem analysis, specification of requirements, program design, design of data structures, coding, testing and documentation. Not only these phases but also others can be carried out by different system developers in their own selection and sequence. Usually, however, there is a fixed working method per company or per project.

Today, these phases are increasingly supported by automatic tools, such as Computer Aided Software Engineering (CASE) tools. Examples of such tools (programs) are: drawing packages for compiling schematic diagrams, syntax checkers, entity relationship diagram packages, consistency control programs, configuration (version) management packages, word processors, programs for creating cross reference lists, programs for standardization of data structures, file and database management packages, compilers, test generators, "make" Utilities etc.

A complete software system will generally consist of several parts, each of which usually only realizes a certain functionality of the whole. The division of the total system into so-called system components is called the architectural design of the system.

During the development process, each system component will go through the different phases of development before a ready-made system component can be said. At any time, a system under development will have a large number of such components. As is known to those skilled in the art, multiple system developers can usually work on developing a large system simultaneously.

An evolving system will therefore at any time consist of a collection of system components, each in its own phase of development.

In order to assess system components on quality, maintainability, complexity, size, testability, stability, etc., various techniques are used, whether or not automated. In this context, particular attention is drawn to the measurement of various parameters of system components, such as, for example, the number of lines of code, the number of different functions, the number of entity relations, the number of functions called, the number of levels of nested routines, etc. Such measured values are known under the collective name "metrics". Hetrics can also be (complex) aggregations of various measured parameters. Examples of such complex metrics include McCabe's metrics (measure of complexity), Rechenberg metric, Halstead metric etc.

In general, metrics are determined for system components that are ready for their development. However, a full or partial redevelopment as a result of an analysis is not abnormal. After this, a new analysis of the system component will be performed to determine whether the component now falls within the criteria criteria.

Storing metrics in files or databases is not new. Metrics of one system component are also stored at different times, so that a specific historical overview of the development of that system component can be made. In general, however, metrics are stored in separate metrics files, which do not belong in the system environment of the system developers, but belong, for example, in the environment of the quality controller, the manager etc. The lack of an optimal integration of metrics with the components that the source of the metrics is considered a disadvantage. After all, in order to determine the parameters of the product under development, the product will have to be made available to the analysis program by the relevant programmer at an appropriate time. The inconvenience to the programmer is interrupted in his normal work, and the fact that steps must be taken by others or possibly by the programmer himself to carry out the analysis have, in practice, shown that the number of times that the relevant parameters are determined during the production process is relatively small. The analysis that can be carried out on the basis of the parameters thus determined is therefore very crude and offers little insight into the course of the development process at random moments.

The object of the invention is now to indicate how the said structural parameters can be determined in detail and in a simple and effective manner, without the programmer or any other special steps having to be taken for this purpose.

This objective is met in a method of the type mentioned in the opening paragraph, that measures have been taken to link the execution of an analysis program, which determines such parameters, to one or more essential elements for the development process and to be executed by the computer. actions, so that whenever the product under development undergoes such an action, said parameters are also determined and the values thereof are stored in a memory.

By determining the structural parameters, which are necessary in the analysis process, each time in combination with an essential action for the development process that cannot be skipped, the analysis program is automatically started without the programmer having to take steps. Since a relatively large number of such actions have to be performed by the computer at relatively short time intervals, it is also achieved that the parameters are also quantified at relatively short time intervals each time and the values thereof are stored in a memory. As a result, a set of parameter values is built up during the development process that can provide a more accurate and detailed insight into the process and the resulting product compared to the existing method.

Preferably, together with the said parameter values, the time at which the values of the relevant parameters were determined is also stored in the memory. This ensures that a clear relationship can be made between the stage of the product and the time it took to reach that stage.

As stated, the invention ensures that during the development process the time of analysis coincides with essential actions. According to a preferred embodiment of the method according to the invention, the action with which the analysis program is linked or integrated consists of the execution of one or more of the following types of computer programs or Utilities (small actions that are usually part of the system environment ): a drawing program package for compiling schematic diagrams, a syntax checking program, an entity relationship diagramming program package, a consistency checking program, a configuration (version) management program package, a word processor, a cross reference list creation program, a program for normalization of data structures, a file and database management program package, a compiler, a test generator, a "make" utility.

In other words, the analysis program is executed automatically whenever a programmer, for example, syntax a system component combined with a syntax checking program, a source code compiled using a compiler or a program documentation (text), produced with a word processor. in a directory, etc.

According to a further embodiment of the method, a separate parameter file is preferably created for each system component of the software under development, in which the values of the determined parameters are stored. Preferably, the separate parameter files have a designation such that the relationship between this parameter file and the relevant system component is immediately clear to anyone who can access the relevant file.

Thus, in the preferred embodiments described above, the invention also affects the format of the metric files, namely, in addition to the source file of each system component (for example, the source of a program part, or the file in which the design of a system part is stored) a parallel create file in which the metrics are stored. For example, the sources of all programs may have file names "abcdefg.c" (for C code) or "abcdefg.pas" (for Pascal code). According to the method of this invention, the associated metric file will now have the extension ".met", ie "abcdefg.met". This makes it easy to include the metrics files in the directories of each programmer and / or project or system. This decentralized storage makes access to the metric files easier and, for example, every system developer can inspect their own metrics files. This achieves greater utility of metrics and reduces "Big Brother is Watching You" syndrome. In order for inspection of all metrics files to be carried out by the central quality department, the programs belonging to them simply need access to all directories of the system developers. In this way, a central metrics database is not necessary, which also prevents the associated work and costs. The advantage is also that the format of the metrics files now automatically follows the structure of the project organization, which will indeed be reflected in the directory format.

Applications of the method according to the invention.

Application 1

By storing information about the development progress of system components in the manner described, statistical material is created to be able to make a model of the development progress. Current developments can be calibrated on the basis of such a model. For example, after measuring the design phase, a prediction can be made about the amount of man-hours that the further development phases will still cost.

As a corollary to this, based on an initial budget for the development of a system component, the budget space can be determined at any time for each development phase and for the entire development process.

Application 2.

By recording information about the development of system components in the manner described, one can immediately detect if major changes in the metrics values occur. Thus, discontinuities in development can be quickly discovered and corrective actions can be taken.

An example of such a discontinuity is, for example, the sudden sharp decrease in the number of functions in a certain module. Normally, the number of functions will increase from the start of a module development. At a certain point, this increase will become more subdued and will not increase again. The development of the module can then continue, but will then include detailed developments per function: the number of functions in that module will no longer change.

However, if during development, the number of functions decreases sharply, and then increases again, it can be assumed with great certainty that the concept of the basic principles of the module has changed. This often occurs after consultation has taken place about various system parts and it is concluded that the coordination was not optimal. A radical functional change is often the result. These so-called "sudden jumps" can now be quickly detected and a corrective action can be started.

Application 3.

The invention makes it possible to detect the occurrence of such "sudden jumps" in all system components and it is possible, based on times of occurrence, to further investigate whether system components with such corresponding "sudden jumps" are interdependent. If system components do not have direct references to each other, this method is a unique opportunity for management to detect dependency.

Application 4.

The analysis program can be arranged in such a way that when predetermined values of certain metrics occur, a warning is given immediately, whereby the implementation of certain development aids is controlled. For example, a standard can be set with regard to the number of levels that can be nested in a program. (Exceeding this would be too complex, making maintenance of the program unacceptably expensive). If the analysis program detects such a violation of this standard, the compilation process can be stopped automatically, for example, or if the analysis precedes the compilation, the compilation does not even have to be done. The system developer can then only proceed if he restructures the system component in this respect.

Such warnings can of course also simply be given to the system developer, who takes action within his own responsibility.

If there are circumstances that prevent such standards from being maintained by the system developer, the procedure may be that he / she must document an explanation. Only after creating a file with such an explanation could the development of the system developer be released to exceed the standard.

Application 5.

Structure metrics provide the ability to provide information about the structure of the system component within system components, separated from details that do not affect that structure. By showing such metrics directly to the system developer after executing a development tool, immediate notification can be made if a system developer makes changes that are beyond his competence. Such warnings can, for example, be passed on to a special file of the quality department, which is regularly warned about such situations. Application 6.

By integrating the analysis with development tools, the load on the computer system can be optimized. The analysis program can, for example, first check whether a system component has undergone relevant changes. For example, a source code can be supplemented with comments, without changing a single statement. A new compilation is then unnecessary, because the compiler will not give any other result than from the previous version of that system component.

Conversely, development tools themselves are sometimes already provided with such controls, so the integration can be used to avoid unnecessary analysis.

The invention will be explained in more detail below with reference to the accompanying figures.

Figure 1 shows the successive programming and compiling steps performed according to the prior art during a software production process.

Figure 2 shows the steps performed during a production process in accordance with the invention.

Figure 3A illustrates for a first selected parameter how the set of the values determined for this parameter can be used for analysis of the software production process.

Figure 3B illustrates a similar diagram to Figure 3A, but now for another selected parameter.

Figures 4A and 4B illustrate the advantage of a detailed parameter set obtained in accordance with the invention when analyzing the software production process.

Figure 1 shows the steps which, as is well known in a software production process, must be performed sequentially. In step 1 a number of lines of code are programmed, in step 2 the obtained program part is compiled, in step 3 more lines of code are produced, in step 4 recompiled, etc. This production process finally ends with a final compilation step at the end of which it can be established that the program is fully functional and free from errors.

In addition to this actual software production process, the values of certain parameters are occasionally determined and possibly recorded or stored. This may include, for example, the number of lines of code that the program has contained so far, the number of modules that make up the program, the number of functions built into the program, the number of memory accesses that the program needs, etc. However, the individual step indicated by the number 5 in Figure 1 is completely separate from the actual software production process (steps 1, 2, 3, 4 .....). In fact, the implementation of this parameter determination procedure is an infringement of the actual production process and as such is experienced by the programmer. The result of this is that in practice this parameter determination step 5 will be carried out only a few times or perhaps not at all, so that little or no insight is obtained into the software production process. What the consequence may be will be explained in more detail with reference to the following figures, in particular figures 4A and 4B.

Figure 2 illustrates a software production process in accordance with the invention. Also in this production process the alternating programming and compiling steps occur again, of which in figure 2 the programming step 1, the compiling step 2, the programming step 3 and the compiling step 4 are specifically indicated. In accordance with the invention, a link has now been made between the compiler used to perform the various compilation steps and the parameter determination program with which parameters of the program in progress can be quantified. This coupling leads to the fact that, as schematically indicated in figure 2, the parameters of this program part are also quantified each time a program part is compiled. More specifically, it can be seen in Figure 2 that the parameter determination step 5a is performed simultaneously with the compilation step 2. Simultaneously with the compilation step 4, the parameter determination process 5b is also executed, etc. By linking the compilation process and the parameter determination process, on the one hand, it is achieved that, whenever possible, the relevant parameters of the program in progress are quantified, while on the other hand, the programmer does not need to take any special steps to this end nor is his normal work interrupted.

It is admittedly indicated in the exemplary embodiment of figure 2 that the compilation process and the parameter determination process take place simultaneously. In reality, the programs in question will run immediately one after the other. However, it is essential that by giving a compilation command the programmer also automatically gives an order to guarantee the parameters of the program concerned. The embodiment shown in Figure 2 can be used with existing compilers. On the other hand, with many existing compilers it will be possible to integrate the parameter determination program in the compiler.

On the basis of the following figures 3A and 3B, it will be attempted to explain how the structural parameters can be used in an analysis process and it will also be explained why the recording of the each time with relatively short time distances and in particular automatically Changing values of the relevant parameters is important to gain a good insight into the progress of the production process.

To simplify the example, an analysis program is assumed that only looks at the number of lines of code that a program contains at a given time and the number of error messages generated by the compiler at the end of each compilation step.

In figure 3A the number of lines of code is plotted against time. At the beginning of the production process there is no line on paper yet and the number of lines of code is therefore equal to 0. This number will gradually increase over time, which growth will generally run relatively steeply initially and towards the end of the production process. will decrease to 0. In the final phase, the number of lines of code will be almost constant and only the last error messages will be eliminated.

Figure 3B plots the number of "error" messages generated by the compiler after each compilation step. This number of notifications can vary and will generally be subject to large fluctuations in that part of Figure 3A where the steepest slope occurs. At the end of the production process, the number of errors will of course have to go to 0 in order to be able to deliver an error-free program as a finished product.

The example of Figures 3A and 3B assumes a relatively large number of valuation points during the software production process. This large number of valuation points yields a relatively accurately determined curve in both Figure 3A and Figure 3B. However, if, as is customary in the prior art, a series of parameters for the particular program is determined only a few times during the entire production process, this may result in a completely incorrect understanding of the production process. An example thereof is illustrated with reference to Figures 4A and 4B.

Figure 4A shows the curve that is obtained if only three values of the relevant parameter, also in this case again a number of lines of code, are available. The three values, indicated in figure 4A with a, b and c, thus yield a normal curve at first sight. However, if this particular production process had been checked in a more detailed way by determining the value of the relevant parameter at a greater number of times, a completely different curve could arise, as shown in figure 4B.

In figure 4B, on the one hand, the same three values a, b and c are plotted with a large number of other guaranteed values for the relevant parameter (the number of lines of code) in between. From the now obtained, much more detailed course, it is clear that there was not a continuous upward trend in the number of lines of code, but that a number of lines of code has been deleted twice, which reduced the total number. Apparently, this programmer spent time writing a few lines of code, which were subsequently deleted. For a manager who has to monitor this programmer, the curve of Figure 4A does not provide any information, while the curve of Figure 4B clearly indicates that irregularities have occurred at certain times in the software production process that should be addressed.

Figures 4A and 4B show that on the one hand the method as used in the prior art has drawbacks which can be eliminated with the aid of the invention.

In summary, it can be stated that by linking the analysis to calling a development program (tool) associated with a process phase, as is done in the method according to the invention, the following advantages are obtained: the analysis takes place at a time determined by the system developer. , after a significant change has occurred in the system component (otherwise he / she would not request any action from the development program) the system developer does not need to take any additional action the system developer can get an overview immediately after the action of the tool he wants of the analysis, which draws his / her attention to various aspects of his work and can respond accordingly, which will positively influence the quality of his work (For example, he / she can be warned after compilation that the number of test paths of his new version has risen sharply, he / she may now see that further development in this The direction will result in a poorly testable module. An adapted strategy can now be considered at an early stage.) Since the development programs belong to a particular development phase, the ".met" files can also automatically store information about that process phase, such as the amount of time spent on the process phase, the number of keystrokes etc. In this way, accurate management overviews can be obtained per process phase. This is a great advantage, because nowadays the information for such overviews is entered entirely manually, which results in little accuracy. Such overviews are fundamental to productivity analyzes.

Claims (11)

A method for analyzing a computer-aided software development process, according to which method at least once during the process one or more parameters of the developing product are determined and compared with corresponding parameters determined earlier in the production process in order to on the basis of this, to gain insight into the development process and the resulting product, characterized in that measures have been taken to link the execution of an analysis program, which determines such parameters, to one or more essential elements for the development process and by computer Actions to be performed, so that whenever the product under development undergoes such an action, the said parameters are also determined and the values thereof are stored in a memory. Method according to claim 1, characterized in that, together with said parameter values, the time at which the values of the relevant parameters are determined are also stored in the memory. Method according to claims 1 or 2, characterized in that the analysis program, with which the said parameters are determined, is linked to or integrated with said actions, essential for the development process, and performed by the computer. A method according to any one of the preceding claims, characterized in that said action, with which the analysis program is linked or integrated, consists of the execution of one or more of the following types of computer programs or Utilities (small actions that usually form part system environment): a drawing program package for compiling schematic diagrams, a syntax checking program, an entity relationship diagramming program package, a consistency checking program, a configuration (version) management program package, a word processor, a program for creating cross reference lists, a data structure normalization program, a file and database management program package, - a compiler, a test generator, a "make ,, * - utility. Method according to any one of the preceding claims, characterized in that the analysis program, with which the parameters are determined, is a program for determining metrics (so-called "metrics"). Method according to any one of the preceding claims, characterized in that immediately after the parameters have been determined, a signal which is perceptible to the human senses is generated by means of the analysis program, so that the person (s) involved in the development of the product concerned keeps an actual feedback. Method according to one of the preceding claims, characterized in that immediately after the parameters have been determined, a report is transferred to another part of the computer system with the aid of the analysis program, in response to which further actions in the development process can be controlled. Method according to one of the preceding claims, characterized in that immediately after the parameters have been determined, a message is transferred to a separate memory with the aid of the analysis program, in response to which further actions in the development process can be controlled. Method according to one of the preceding claims, characterized in that a separate parameter file is created for each system component of the software under development, in which the values of the determined parameters are stored. Method according to claim 9, characterized in that the separate parameter files have a name such that the relationship between this parameter file and the relevant system component is immediately clear to anyone who can access the relevant file. Method according to any one of the preceding claims, characterized in that the analysis program determines on the basis of criteria determined whether an unexpectedly strong change has occurred in one or more of the parameter values and also if such an unexpectedly strong change has occurred. checks the values of the other parameters to determine whether an unexpected significant change has occurred (almost) simultaneously with other parameters.