A Shortcut Guide to ADP

ADP Principles

Principle 1: Establishment of Infrastructure
"Build a strong foundation through integration of people and technology"

• People
• Configurable technologies
• Integration of the people and the technology

Principle 2: Application of General Best Practices
"Learn from others' mistakes"

• Best practices from industry experts
• Prevent common errors

Principle 3: Customization of Best Practices
"Learn from your own mistakes"

• Each time a defect is discovered, a new customized practice is defined and integrated into the process
• Application should be automated and seamless
• Adherence should be monitored

Principle 4: Measurement and Tracking of Project Status
"Understand the past and present to make decisions about the future"

• Identify problems promptly
• Assess product quality and deployment readiness
• Requires automated reporting system

Principle 5: Automation
"Let the computer do it"

• System complexity makes automation a necessity
• Automation...
  • Improves job satisfaction and productivity
  • Improves product quality
  • Facilitates human communication
  • Helps to implement and verify best practices and organizational standards
  • Facilitates control of the software processes by collecting measurement data

Principle 6: Incremental Implementation of ADP's Practices and Policies

• Group-by-group
• Pilot group > expansion
• Practice-by-practice
• Severity levels
• Cutoff dates

Feedback Loop

1. Identify a defect.
2. Find the root cause of the defect.
3. Locate the point in the production line that caused the defect.
4. Implement preventative practices to ensure that similar defects do not reoccur.
5. Monitor the process to verify effectiveness of the preventive practices.

Essential Infrastructure Components

The foundation of a robust development infrastructure includes the following components:

Source control system: Having a source code repository is a prerequisite for nightly builds. All of the files needed for the build should be in the source control system, including build files, scripts, etc. – not just the source that is being built.

Nightly build system: This system builds an application on a regular basis by automatically executing the required build steps at the scheduled time without any human intervention. This way, any problems are detected the next day (as opposed to a week or more later).

Requirements management system (and/or bug tracking system): This is a repository for storing and tracking defects and issues, as well as the developers' ideas for improving the application. Defects are stored so they can be tracked, analyzed, and ultimately prevented from recurring. The system can also be used for storing feature requests and tracking feature and requirement changes. The end result is a central repository of information related to your software.

Regression testing system: A regression system is any tool or combination of tools that can automatically run the core of the existing tests on the entire code base on a regular basis. Its purpose is to identify when code modifications cause unexpected faults, especially those faults that occur because a developer did not fully understand the internal code dependencies when modifying or extending code that previously functioned correctly. For example, it can be established by running automated testing tools from the command line using scripts or Ant with CruiseControl or Maven.

Other tools: This can include tools for static analysis, code review automation, performance profilers, memory analyzers, coverage analyzers, etc. For example, this could include open source tools such as PMD, JUnit, CppUnit, NUnit, or automated tools such as Parasoft Jtest (for Java), C++test and Insure++ (for C/C++), .TEST (for .NET languages), WebKing (for Web applications), and SOAtest (for SOA).

Reporting system: This system should be able to gather data from all these components (source control, nightly build, tests, etc) and present them in a visual way to enable analysis of status and trends.

Visibility into Your Development Process and Products

When the recommended infrastructure is implemented, a reporting system collects and correlates data to provide a comprehensive and objective assessment of the application itself, as well as the processes used to produce it. These results are presented in the form of a graphical dashboard.

The information presented in this dashboard can help you answer questions such as:

• How long will it take to implement currently-scheduled features/requirements?
• Are features/requirements being properly implemented?
• Is team-wide productivity improving?
• Is the application reliable enough to release?
• Are there any undesirable trends that suggest that the number of defects is not under control?

Moreover, the reporting system's dashboard can automatically alert you to potential problems, including:

• Slow code base growth: This might indicate that productivity is dropping, the team is working on other projects, the team is working on code but not checking it in, or an outsourcer is adding code intermittently.
• Feature requests (FRs)/problem reports (PRs) were marked as resolved, but code was not added or modified: This might indicate that features/bug fixes are being marked as resolved before they are really implemented. This is a process problem that could impact the accuracy of your readiness assessments and scheduling estimates. Or, it could indicate that code for the features/bug fixes is not being checked into the source control system and thus is not being integrated into the application.
• Code is being added faster than it is being reviewed: The number of code review tasks should remain stable (or decrease) as long as the code is being added at a steady rate. If the code is being added at an increased rate and the number of review tasks increases but does not stabilize, consider dedicating more resources to code review.
• New code lacks tests: Developers might be creating new code without also creating tests to verify that code. Or, they might be checking in new code, but not adding the corresponding new tests to the source control system. Either way, the team is not following the best practice of adding test cases for new code; as a result, the regression test suite is not checking the continued functionality of that code.
• Functional test cases are not being built for resolved FRs/PRs: Functional test cases are not being added to verify FRs or PRs that were marked as resolved. One explanation is that developers are not creating the appropriate test cases; another is that the test cases were created, but not checked in to the source control system. Either way, the team is not following the best practice of adding test cases before marking features/requirements as resolved; as a result, the regression test suite is not checking the continued functionality of the feature or bug fix.