Welcome!

Linux Authors: Pat Romanski, Elizabeth White, Dana Gardner, Yeshim Deniz, Kira Makagon

Related Topics: Linux

Linux: Article

Automated Error Prevention for Linux

Protect the reliability and cost-effectiveness of Linux

Most organizations that use Linux as a business operating system are developing their own applications for Linux - perhaps in response to the current scarcity of packaged applications available on Linux. With so much internal development for Linux, it is critical that the IT groups building your Linux-based applications have a means to efficiently produce reliable code. If they don't, you will jeopardize the very reliability and cost-effectiveness that most organizations are trying to achieve by turning to Linux.

However, most development teams follow a development process that is far from efficient, and the applications they provide typically experience functionality problems and security weaknesses that require patches, updates, and redeployments. In fact, most IT organizations waste a great deal of their time, effort, and resources fixing what is essentially the same error. As a result, applications are not deployed on time and on budget, applications are not reliable, and/or the organization's developers are probably following the standard rule of 80% time spent debugging and 20% time spent writing new code. Here's why: traditional software testing methodology tries to control costs and improve quality by promoting the tactic of testing "early and often." If an error is detected at any time during the software life cycle, a bug report is filed, the responsible developer tries to reproduce and repair the problem, then testing must verify that the modification corrected the reported problem and did not introduce any new problems. This approach is not only time consuming and costly, but also inefficient because it doesn't do anything to prevent the same types of errors from happening again. Consequently, a single IT group probably wastes a significant amount of time, effort, and resources on the same types of errors thousands of times over.

With the error prevention knowledge and technology available today, an IT development team should never encounter the same type of software error twice. By applying a concept called Automated Error Prevention (AEP), you can ensure that any time an error is discovered, the development process is improved, and that error - along with entire classes of similar errors - is prevented from recurring. If this methodology is implemented throughout your organization's IT groups, the developers will have the infrastructure and process essential for efficiently producing applications that leverage the strengths of Linux.

What Is the Parasoft AEP Methodology?
The Parasoft AEP methodology defines the practices that apply the concept of AEP to the software life cycle, and describes how those practices can be used in a group environment. The concept of AEP advocates the automation of five specific procedures, which are combined to improve the development process and prevent software errors:

  1. Detect an error
  2. Isolate the cause of the error
  3. Locate the point in the process that created the error
  4. Implement practices to prevent the error from reoccurring
  5. Monitor for improvements
The key to AEP is that you should find a bug only once (or learn from someone else who has already found and analyzed that bug). The knowledge you gain from finding and analyzing bugs should be used to improve your process so that you never encounter repeat occurrences of bugs similar to those you have already found.

For example, imagine that you have an n-tier system that includes a client, middleware written in Java, and a database. Assume that load tests revealed that a heavy load stopped the system. After detailed analysis, you discovered the problem was caused by a resource leak from open connections to the database. Normally, you would simply identify and modify the code to close the connection.

However, if you were to approach this situation from the perspective of AEP, you would try to determine how to prevent the problem from recurring. After isolating the problem as an open connection, you would determine that the error was introduced because a developer wrote code to open - but not close - a connection. You might then try to stop this error from recurring by implementing a practice that ensures that code written to open a connection is always accompanied by code to close that connection.

One way to implement this practice is to establish a Java coding standard requiring that each class that opens a connection must have a finalize() method and the finally block to close the connection. If code follows this rule, the error won't reoccur. But how will you enforce this? You could try to enforce the practice by having the team conduct code reviews. However, this is inefficient because the team would need to manually review and analyze all of the code to determine whether all of the connections were closed.

A more efficient strategy is to use a static analysis tool that can analyze the code and automatically identify any violations of this guideline. The team can then prevent leaks by ensuring that all connections are closed.

This is the idea behind AEP. You found an error during load testing, then isolated the error's source as a resource leak from an open connection in the Java middleware. You found that the Java code was missing a finally block and finalize() method, defined a coding standard to specify how code should be written in the future, and automated the process to ensure that this standard is actually followed.

How Is AEP Implemented?
You implement AEP by defining error prevention practices - including coding standards, static analysis, unit testing, regression testing, load and stress testing, functional testing, integration testing, application testing, and monitoring - and integrating these practices into the software life cycle as shown in Figure 1.

 

Whenever an error is detected during a specific practice, you modify an earlier practice to prevent that error and all similar errors. For instance, in the example from the previous section, an error was identified during load testing, then the coding standard checking practice was modified to include a new coding standard.

How Do I Implement AEP Practices?
The way that you implement AEP practices can determine whether AEP becomes an effective and sustainable part of the development process, or just another fad that sounded good in principle, but never produced the promised results. Each AEP practice implemented must satisfy three requirements for success. Each practice must be:

  1. Implemented as a group practice
  2. Embedded in the software life cycle
  3. Automated to ensure that it does not decay
All three requirements are critical for every practice, which is why I recommend that you implement each practice in a similar manner. The recommended group workflow for all practices is described in Figure 2.

 

To achieve automation, you ensure that each developer is equipped with the technology required to automate the practice. The technology might be scripts or programs developed internally, open source tools, or commercial tools.

To promote the necessary uniformity and enforce group behavior, you ensure that all team members are automating the practice in exactly the same way, and that only the team architect can modify the tool settings. Moreover, to maintain the integrity of the code base, you require that developers apply the practice to their code before they add that code to the source control system. Any practice violations must be remedied before the developers check in the code.

To verify that developers actually adhere to the required practices, you configure the technologies that automate the practice to run regularly scheduled batch mode tests on the code available in the source control system. No violations should occur at this point. If any do occur, the tools notify the architect and the developer; this notification serves as an invitation for a code review. During the code review, the architect and developer review the violation of the practice and determine whether this was an appropriate violation.

Information from the regularly scheduled batch mode tests should be collected in a central location (such as a relational database), and then analyzed to measure how well the practice is implemented. In addition, managers can use this information to better assess group productivity and project progress.

A Final Word
The software industry must mature, and there can be no maturation without effective error prevention and process improvement. We have no other options - we must do it. If we don't, we will pay dearly for it in functionality and security problems, excessively high development costs, and depressingly low productivity.

The Parasoft AEP Methodology
The Automated Error Prevention (AEP) Concept has been developed over the course of many years through close work with the software industry, Parasoft development personnel, and the personal dedication of Dr. Adam Kolawa, chairman and CEO of Parasoft Corporation. The AEP Concept addresses a basic need within the software industry, that of improving application quality through the automatic prevention of errors during the entire software development lifecycle. We believe that the AEP Concept is fundamental for improving the efficiency of the software industry and is critical for the software industry to mature.

Because the AEP Concept is so important, it must be shared with others in the industry. Therefore, Parasoft is pleased to place the Automated Error Prevention (AEP) Concept, the "five steps plus automation," into the Public Domain. Parasoft is very committed to the AEP Concept, and wishes to see it embraced by companies and organizations that want to improve their software manufacturing and development processes. We encourage others to adopt the Parasoft AEP Concept, to improve it or change it as needed, and build their own methodologies and products from it. To this end, Parasoft will soon unveil the AEP Consortium, a think-tank that will bring together software corporations and leaders to foster support and practical implementation techniques for the AEP Concept.

Parasoft AEP Methodology is a specific application of the AEP Concept to the software development life cycle. It defines how you place the automated procedures into the software life cycle and how you ensure that the development group works together to implement and maintain the practice. The Parasoft AEP Methodology is not a product. Rather, it is the definition and description of a process in which proven error prevention practices are automated for the software development industry.

We believe that there are other AEP Methodologies that are waiting to be discovered and applied to the software development life cycle, and we encourage others in the software industry to conduct research to facilitate the creation and dissemination of these additional methodologies. We have simply conducted the first phases of this research - there is still much more that can be done.

Parasoft AEP Solutions are specific implementations of the Parasoft AEP Methodology that combines tools, services, and know-how to support the full software life cycle. Companies such as IBM, Cisco, and Warner Music Group have adopted Parasoft AEP Solutions and are already reaping benefits throughout their entire software development programs.

More Stories By Adam Kolawa

Adam Kolawa is the co-founder and CEO of Parasoft, leading provider of solutions and services that deliver quality as a continuous process throughout the SDLC. In 1983, he came to the United States from Poland to pursue his PhD. In 1987, he and a group of fellow graduate students founded Parasoft to create value-added products that could significantly improve the software development process. Adam's years of experience with various software development processes has resulted in his unique insight into the high-tech industry and the uncanny ability to successfully identify technology trends. As a result, he has orchestrated the development of numerous successful commercial software products to meet growing industry needs to improve software quality - often before the trends have been widely accepted. Adam has been granted 10 patents for the technologies behind these innovative products.

Kolawa, co-author of Bulletproofing Web Applications (Hungry Minds 2001), has contributed to and written over 100 commentary pieces and technical articles for publications including The Wall Street Journal, Java Developer's Journal, SOA World Magazine, AJAXWorld Magazine; he has also authored numerous scientific papers on physics and parallel processing. His recent media engagements include CNN, CNBC, BBC, and NPR. Additionally he has presented on software quality, trends and development issues at various industry conferences. Kolawa holds a Ph.D. in theoretical physics from the California Institute of Technology. In 2001, Kolawa was awarded the Los Angeles Ernst & Young's Entrepreneur of the Year Award in the software category.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Dan Kegel 12/29/03 11:59:48 AM EST

Parasoft just wants to sell you expensive tools.
Skip their sales pitch, and go check out Valgrind
(http://valgrind.kde.org). It's a free tool that
finds a lot of the same problems the Parasoft tools
do. And it doesn't even require you to recompile your
apps. Valgrind was used recently by the Openoffice team
to find and fix a large number of subtle bugs in their
extremely complex C++ app. If it's good enough for Openoffice,
it's good enough for your app. Valgrind rocks!