Data processing: software development – installation – and managem – Software program development tool – Software project management
Reexamination Certificate
1997-10-21
2003-01-28
Morse, Gregory (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Software project management
Reexamination Certificate
active
06513154
ABSTRACT:
FIELD OF THE INVENTION
The field of the present invention relates in general to a system and method for automatically tracking, measuring, and facilitating the progress of software development in a digital computer system. In particular, the present invention relates-generally to software development management systems; particularly Gantt chart software, defect tracking systems, and debuggers by providing a code based software development management and automated debugging system.
BACKGROUND OF THE INVENTION
The management of software development is a new and difficult discipline. The inadequacy of software management techniques is demonstrated by repeated studies showing that at least seventy percent of all software projects are never completed. Without detailed, accurate measurement, runaway development costs, particularly in large organizations, are difficult to detect and stop. To track all the aspects of a project accurately, software development managers need an ongoing awareness of each developer's activities, the option to transfer sections of code easily from one developer to another, and measurable criteria on which to base shipping decisions. The development process still costs at least one hundred dollars per line of code, with a typical software project containing thousands of lines of code; As development progresses, costs go up as a manager's ability to effectively manage the project goes down.
Most managers rely on Gantt charts to track a project's progress. However, Gantt charts require regular manual updating in order to accurately reflect the progress of the project. Managers, when under pressure to complete software, neglect to update the Gantt chart, making the Gantt chart irrelevant. Even if Gantt charts are updated regularly, they are of limited use because they are based on what people say: genuine complexity and technical-jargon make code overwhelmingly intimidating for anyone but its author to understand. Consequently, one of the few aspects of a modem large business enterprise that cannot be audited is software development.
Further, every time code is changed (“versioned”), its behavior will change in a way that cannot be predicted. Most of these changes produce intended and beneficial behavior, but some produce neither beneficial nor intended behavior. Erroneous, detrimental or deleterious behaviors are common called bugs. Bugs, which are introduced by new versions, are often not detected until long after they are introduced. Bugs remain undetected because most users have neither the time nor the tools to run regression tests, which check that working code remains working after it's been changed.
Automated version control systems have been an integral part of software engineering for many years. They attempt to address the above noted, intrinsic problems of code development by essentially providing a data store for versions of code. Prior art enhancements to version management do notify managers about code changes, but don't teach how to use version derived information to update Gantt charts.
Developer's Information Monopoly
The central underlying problem is the developer's monopoly on information. If two developers (A and B) have the same level of skill, developer A cannot easily understand B's code and vice-versa. Therefore, only A can effectively work on A's code. This is what will hereafter be referred to as the “developer's monopoly on information.” Previous enhancements to version control systems have attempted to break the developer's monopoly on information by forcing developers to enter reasons for entry and/or linked this with “diffs” (versions with textual differences highlighted) of the code, but these systems are limited by forcing the developer to manually explain the reasons for the changes. Further, these enhancements don't teach how to derive the developer's intent directly from the code.
Problems of the Individual Developer
Code is so complicated that it is extremely difficult for an individual engineer to maintain quality as it evolves. Bugs, new and existing, are one of the most unavoidable, annoying, and time-consuming problems in the development of code. Each bug is unique, which is why there have been no successful automated debugging tools. However, bugs can be grouped into general classes:
Crashes: Crashing is the most severe, and one of the most common, errors. Developers often don't know what caused a crash, so cannot reproduce and fix the problem. In addition, developers will sometimes leave crashes in a program in the rush to ship code.
Endless Loops: Developers often accidentally write endless loops. When a program hits an endless loop, it continues to run/loop until the program (or the computer) is shut off. Endless loops are particularly time consuming because the developer doesn't know the cause, and may assume the program is just being slow instead of endlessly looping; Therefore, discovering endless loops takes a great deal of time.
A Statement Is Not Executed When It Should Be: One of the most common types of discrepancies is that a statement (line of code) will not be executed under conditions where the developer intended that it should. Sometimes these bugs are simple to solve, but, when they aren't, their causes can take hours to find.
Bad Data: An even more time consuming-type of bug is finding out why a particular number or other piece of data is not what it should be. Sometimes the reason is simple, but often the number that shows up incorrect is the result of a calculation that occurred incorrectly somewhere else in the program. This incorrect calculation causes a chain reaction that manifests itself in the bad data that was originally detected. The developer must laboriously track this chain of data back to its source.
Something That Used To Work No Longer Does: Developers frequently make changes in code that breaks previously working code; This often happens when a developer is editing the code to address a problem in one area and does not anticipate the effects of the edit on other areas of functionality. Regression tests, well described in prior art, are an attempt to catch these types of inadvertently created bugs. However, regression tests only provide pass/fail information and do not pinpoint the edit that caused the break-. Further, the demands of development consume the time that developers might use to go back and test thoroughly. While quality assurance organizations have banks of regression tests that are automatically run, these require releasing the code to QA: so, they aren't run on the code while it's being developed.
Transferring Code is Difficult
The developer's information monopoly applies not only to managers but also to other developers. This monopoly makes it hard to take over another developer's code, especially-when the original developer is not available to explain the code. Most developers taking over the project will look at the code, and say it needs a rewrite (because they write differently). This rewriting is likely to introduce new bugs, making the program less solid than it was when transfer occurred.
Code transfer is a common, and expensive, software management problem. While many academic and commercial attempts to solve this problem have been tried, no successful automated system for code transfer has been developed.
Application Ser. No. 08/955,028 filed Oct. 10, 1997 (now abandoned) by the assignee herein provided beneficial features of “automatic bugs” and is incorporated herein by reference. Application Ser. No. 08/955,835 file Oct. 10, 1997 (now abandoned) by the assignee herein provided beneficial features of “the monitor process” and is incorporated herein by reference. Application Ser. No. 08/955,163 file Oct. 10, 1997 (now abandoned) by the assignee herein provided beneficial features of “Implicit Ul Test” and is incorporated herein by reference. Application Ser. No. 08/956,651 file Oct. 10, 1997 (now abandoned) by the assignee herein provided beneficial features of
Ingberg Todd
Morse Gregory
LandOfFree
System and method for testing of computer programs in... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for testing of computer programs in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for testing of computer programs in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3059120