Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
1998-07-08
2001-08-14
dela Torre, Crescelle N. (Department: 2173)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S950000, C717S152000
Reexamination Certificate
active
06275223
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to a method and apparatus for inspection of computer code.
BACKGROUND TO THE INVENTION
Conventional modem communication systems rely heavily on physical resources which are controlled by data processing devices, eg, switch fabrics, routers, frequency channel assignment apparatus, networked personal computers, network management systems and the like. Data processing devices typically operate in accordance with the known Von Neumann methods, in which a large number of logic elements eg, bi-stable devices, transistors or the like sequentially switch between states under control of (typically) electronic signals. Large collections of such signals comprise a know computer program. At a higher level, the individual signals which control individual logic devices are assembled from a set of instructions written in a known computer language. Such instructions are generically referred to as code. A conventional computer program may contain hundreds of thousands, to tens of millions of lines of code. For example, a main control program for the known DMS100 broad band switch manufactured by Northem Telecom Limited contains of the order of ten million individual lines of code and is written in a proprietary programming language. Programs of more modest length may typically have between one hundred thousand, and three million lines of code. In general, as computing resources become more powerful, and program developers take advantage of increased computing power to provide more and more features, there is a generalised tendency within both the Telecom's and computer industries for programs to become more and more complex, to contain greater numbers of lines of code.
In U.S. Pat. No. 5,428,729 (IBM) there is disclosed a data processing system having a plurality of workstations for generation of a software application package by a plurality of programmers under control or a metaprogrammer. An object of U.S. Pat No. 5,428,729 is to automate management of a design through the implementation of a software application.
In any communications system, whether packet switched or circuit switched, reliability and robustness are of primary concern, and due to the high dependency of communication systems on program control, de-bugging and improving programs by way of regular code inspections is of primary importance, and is an essential part of the construction process of any program.
The code inspection process operated at Nortel (Northem Telecom Limited) involves calling a meeting between a team of program developers responsible for a program or a section of a program in order that the code can be inspected, and any potential problem areas in the code identified. An overall development process for a program involves many such code inspection meetings. After each code inspection meeting, the developers attempt to modify or re-write any code lines for which they have responsibility, and which have been identified as being problematic or capable of improvement at the code inspection meeting.
Referring to
FIG. 1
herein, there is illustrated in general a code inspection process. In an overall development cycle of a program, many such code inspection processes will occur on various components of a program. Regular code inspections during a program build have the direct advantages of increasing software quality, identifying errors early on in a development cycle, decreasing testing time, reducing reworking and improving efficiency of error detection. Indirect advantages include increases in customer satisfaction through better more reliable products.
Typically, a code inspection meeting is organised according to the following format:
Code inspection meetings occur for selected sections of code or modules of code of a program, not for a complete program.
In step
100
a manager or program developer calls a code of inspection meeting, to be attended by a team of developers working on a particular portion of code, subject of the meeting.
In step
101
, prior to the code inspection meeting each developer photocopies a print out of the particular code portions on which they are working and for which they have responsibility.
In step
102
, typically, three or four developers will attend a code inspection meeting, and the code inspection meeting may last of the order of two hours.
At the code inspection meeting, individual lines of code are inspected by all or some developers on a line-by-line basis. Each developer makes notes of any proposed changes to the particular portions of code for which they have responsibility. Responsibility for the overall progress of the meeting and responsibility for recording changes of code is designated to one developer or manager, who is known as a “moderator”.
In step
103
, after the meeting the moderator, or one of the developers prepares typed or written minutes of the meeting identifying lines of code which are to be changed, and any proposed changes to that code. Then, one or more of the developers re-work the code The developer who is responsible for a particular portion of code makes the changes.
Changes to the actual working copy of the program are not made at the meeting—these are to be carried out later by the individual developers. A re-work follow up meeting is optionally carried our in step
104
.
Although code inspection meetings are an essential part of building a program, there are several problems associated with such meetings. Firstly, good experienced program developers are scarce, and their time is valuable. Having three or four program developers spending time photocopying code, and having a program developer preparing minutes of a code inspection meeting is not an optimum use of their time. However, preparing material to bring along to a code inspection meeting is a skilled task, and therefore needs to be carried out by developers and is not easily delegated. Secondly, preparation of minutes of the meeting introduces a delay into product development, since programmers may not address problems identified at the code of inspection meeting until the typed up minutes of the meeting are available. Thirdly, developers may be situated at physically separate locations, for example either at different locations within a same building, within an area of a few hundred meters of each other at different sites a few miles or tens of miles apart, or in a multi-national organisation, developers may be located on different continents. In the latter case, it may only be practicable for a developer to ‘attend’ a meeting by telephone conference call. Fourthly, there is the problem that the rate at which lines of code can be inspected is relatively low. For example, in a two hour meeting attended by four developers, where good progress is made, of the order of eight hundred to one thousand individual lines of code may be inspected (a good rate of code of inspection of around two hundred and fifty lines per developer hour). Thus, for a moderate size program of for example one hundred thousand lines of code, inspecting every line of code once would incur of the order of four hundred developer hours of code inspection meetings if a good rate of code inspection were achieved. However, such a code inspection overhead is unrealistic, since the necessary resource of developer time is unavailable, and if available, would be better utilized on other tasks. Further, it may be that some lines of code require more than one code inspection. For a large program, eg, ten million lines of code, it is not practicable to inspect every line of code, and in practice for most programs only 10 to 20% of lines of code are inspected, and it is accepted that there will be bugs and errors within programs. Typically, 20% pf the most complex code is responsible for of the order of 80% of all errors in a program. Complexity analysis tools are available for identifying the most complex portions of code. One such example is the QAC tool which is a C static analyzer which serves as a tool to help coders to check that their code adheres to recognized
dela Torre Crescelle N.
Lee Mann Smith McWilliams Sweeney & Ohlson
Nortel Networks Limited
LandOfFree
Interactive on line code inspection process and tool does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Interactive on line code inspection process and tool, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Interactive on line code inspection process and tool will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2465886