In-Depth

Solid Infrastructure Paramount to Successful Outsourcing

Implementing a preventive methodology helps establish a solid infrastructure, raising the outsourcing organization's accountability, forcing them to write better code

• By Adam Kolawa
• 06/14/2005

Development of a stable, solid infrastructure is the beginning of any successful project. Project outsourcing is no different. The key to a solid infrastructure is a preventive methodology that provides the ability to centrally manage software quality in a decentralized development environment. The methodology also offers visibility into the code base to ensure consistency in code quality and standardized best practices. It’s like installing a window into the development process, enabling you to see inside to the core. You can tell whether your projects are truly stable and under control, which is especially helpful and insightful for outsourced projects. A specific example of a good preventive methodology is the Automated Error Prevention (AEP) Methodology. It is not a product, but rather a process in which proven error-prevention practices are adopted and automated for the entire software development lifecycle. There are other methodologies waiting to be discovered and applied to the software development lifecycle. Parasoft Corporation, which I lead, has conducted the first phases of this research, and there is still much more that can be done. Others in the software industry are encouraged to conduct research to help create and disseminate these additional methodologies.

Implementing a Preventive Methodology

The most painless way to implement a preventive methodology is to use one that provides a well-tested blueprint of clear and practical guidelines for every implementation detail—from the required practices and infrastructure elements, to a plan for introducing each practice and element, to a team workflow that makes the most efficient use of the prescribed practices and elements. This can be done by leveraging the experience and research represented by the AEP Methodology.

There are five main principles to the AEP Methodology:

Principle #1: Apply industry best practices to prevent common errors and establish a foundation for full-lifecycle error prevention.

At a high level, the software lifecycle always looks the same. To anchor basic error prevention into the common software lifecycle, integrate industry-accepted best practices (such as coding standards, unit testing, and integration testing) into the lifecycle and automate these practices as much as possible.

By adopting industry-standard best practices, you can instantly progress from following the few best practices your organization has developed over the years to using a comprehensive set of best practices been developed, tested, and perfected by industry experts who have analyzed vast amounts of code—and errors—worldwide. You inherit the benefits of tremendous experience without having to perform any of the groundwork required to acquire that experience.

Principle #2: Modify practices as needed to prevent unique errors.

Inevitably, some errors will slip through industry-standard practices because every development process and project has its own unique challenges. You can implement a methodology that anticipates these unique errors and provides a mechanism for customizing the practices to prevent the errors. Each time you discover an error that evades existing error-prevention practices, apply the following five-step procedure:

1. Identify the error.

2. Determine the cause of the error.

3. Look upstream in the software lifecycle to determine the root cause of the error.

4. Modify an existing practice (or implement a new one) to prevent that type of error from recurring.

5. Check adherence to that practice to monitor whether it is being followed.

As a result, the development methodology becomes increasingly error-resistant with each bug identified.

Principle #3: Ensure that each group implements practices correctly and consistently.

To do so, follow these tips:

• Introduce practices on a group-by-group basis. Start with one group; after this group has effectively put practices to use, start another group, and so on.

• Ensure that each group has an appropriate supporting infrastructure. Each group must have a functioning source-control system and automated-build process before its members can effectively implement error-prevention practices.

• Implement a group workflow that ensures error-prevention practices are performed appropriately. Everyone in the development group must understand his or her role—be it developer, architect, QA, or project manager—and must understand how to adhere to that role given the practices in place. For example, understanding who creates coding standards, where these standards are stored, and who uses them (and when) is necessary for the group to successfully adopt automated coding standards that remain ingrained and do not deteriorate over time.

Principle #4: Phase in each practice incrementally.

Introducing practices in phases eliminates the team from being bombarded with learning and following an unmanageable number of new requirements at once—in addition to performing their normal job responsibilities. Try one of the following strategies:

• Divide each practice into several levels—critical, important, and recommended—then introduce each level incrementally.

• Apply the practice only to files created or modified after a predetermined "cutoff date," or, even better, apply the practice only to the specific lines of code created or modified after the cutoff date.

Principle #5: Use statistics to stabilize each process, then make it capable.

Error-prevention practices will not deliver maximum benefits until processes are stable and capable. A stable process is predictable, with its variation under control. A capable process is stable. If a process is stable but is not capable, the group must determine what process modifications would raise their confidence factor measurements, modify the process accordingly, and continue plotting and analyzing this variable until it is both stable and capable.

Applying Preventive Methodologies to Outsourcing

How do you apply this methodology to an actual development project—specifically, to a project being developed in a decentralized development environment? Essentially, you need to apply the first three methodology principles at the outsourcer site and the last two at the local site. The application of all five principles can be facilitated by a system that hooks up to the source control system that takes the code, scans it on a regular basis, and pulls out different metrics.

There are multiple ways to implement this system. The most common arrangement is to add to your outsourcer contract the requirement that those working with your code use error-prevention systems. The outsourcer must also be required to use an error-reporting engine accessible to you.

To illustrate how how this scenario is applied, imagine managers in the U.S. watch this system (perhaps located in India) and the daily reports verify that specifications are being implemented.

Management can look at code that is checked in to the source control system to see if the outsourced developers are working on it and adhering to standards, as well as to verify that specifications are being met. Test statistics can be reviewed that tell managers whether the outsourced developers are actually testing the code and coverage.

Conclusion

Implementing a preventive methodology conveys to the outsourcer that you are aware of exactly what they are doing. It sets the basis for a solid infrastructure and has a positive effect on the outsourcing organization because it raises their accountability, and thus encourages them to write better code. Development environments (current tools, processes, and methodology) can be leveraged to increase productivity and reduce the costs of deploying an enhanced quality program.