Summary

Audit allows to check compliance of a software system and an infrastructure with well-known and up-to-date practices.

The audit procedure covers the following types of a technical debt:

• Production debt
  This debt implies high risks for a product. It focuses on observability (e.g., effort to troubleshoot an issue), portability (e.g., effort to deploy a new version) and security (e.g., possibility of a security breach).

• Development debt
  This debt implies moderate risks for a product. It mostly focuses on maintainability (e.g., on effort to introduce a new feature).

• Involvement debt
  This debt implies moderate risks for a product. It mostly focuses on understandability (e.g., on effort to introduce a new developer).

Workflow

Audit is a recommended activity during ownership transfer and release preparation. The audit procedure includes the following steps:

• Kickoff
  Depict scope and obtain access.

• Preparation
  Approve checklists and estimates.

• Examination
  Check compliance using checklists.

• Reporting
  Prepare and distribute report.

The audit report must include the following parts:

1. Components
   Input list of software components for audit.

2. Checklists
   Input list of checklists for audit.

3. Issues
   Output list of found issues.

Optionally, report may include expected resolutions for found issues. The recommended resolutions for issues:

1. Accept issue and rework software.

2. Reject issue and document reasons.

Checklists

The audit checklist consist of inspections. Each inspection has a requirements level (RFC 2119):

• must
  Inspection is a requirement; noncompliance will cause a significant debt and may cause issues in production, development or involvement.

• should
  Inspection is a recommendation; noncompliance may cause a manageable debt.

There are platform-independent and platform-specific checklists.

Platform-independent checklists:

Platform-specific checklists: