littletree logo

Ada Software Auditing


A software audit is a review by a team of expert Ada developers of the source code of a Ada software project. Peer review has been proven to be the most effective method of locating software defects and improving the overall quality of software. Auditing by external experts delivers the effectiveness of peer review but offers the additional benefit of independent auditors that are not biased with prior knowledge of the software. External auditors are also unencumbered by project history, political issues, or personal bias.

Software Auditing is best performed before key release points in the software development lifecycle. An audit can be performed after detailed design is complete to check the integrity of the program structure, type model, data model, error-handling model, and multi-threading design if present. Validation of the design at this point can potentially save more costly restructuring efforts in later lifecycle phases. More mature software can be analyzed for code defects, internal consistency, efficiency, and adherence to project standards. Well established code can be audited for portability, reusability, and its future maintainability.

The Ada Analyzer, a static analysis tool with the ability to analyze code in many dimensions, will assist auditors in the locating Ada constructs that impact the analysis objectives of the audit. The Ada Analyzer can be used initially to help the auditors understand the structure and content of the code. The tools also locate all instances of Ada constructs matching some analysis requirement. It can find the "needles in the haystack" in voluminous amounts of code and do so with computer speed.

Audit deliverables consist of reports that describe specific quality issues, and a list of all instances in the code that violate or impact that issue. Reports are delivered in two formats. An online form, with hypertext links to actual Ada constructs, can be used interactively to further investigate reported constructs "in context" to decide whether an update is required. Hard copy reports with line number locations of all reported constructs can be distributed at review meetings, or sent via e-mail to individual developers responsible for sections of the code. It is expected that all reports will be scrutinized carefully before a decision to modify the software is made. Some changes may be deemed too risky to incorporate into mature code that is well tested and functioning "correctly". Detailed reports will allow projects to make an informed choice as to which modifications have the right risk-benefit tradeoff.

Audits can be tailored to fit the project-specific requirements and priorities. The following analysis objects can be selected and prioritized by the requesting project.

Program design and structure: This audit objective illuminates how a software system is designed and structured. It locates key program structures and offers condensed information about their use throughout the program. Analysis includes packaging, data typing and object declaration, subprogram interfaces, and dependency relationships of all items. In addition to providing a better understanding of a program’s structure, this analysis can often suggest restructuring opportunities, identify redundancy and obsolete items, and locate inconsistencies across the software.

Code correctness: This audit objective locates both code defects and constructs that have a higher likelihood of error in future maintenance phases.

Code efficiency: This audit objective locates constructs that generally have a high impact on code size and/or run-time speed. This information coupled with a good understanding of the cross-compilation tools can rapidly identify opportunities for improved efficiency.

Conformance to programming standards: This audit objective locates items that violate project programming standards. This can range from simple usage of prohibited constructs to more complicated interaction between constructs. Analysis can also customized to check for specific project conventions or consistency requirements.

Software content: This audit objective locates and counts construct usage at various levels of detail from the very high level to highly precise information on low-level constructs. This can be used to profile software or to quickly locate all instances of a specific construct that has been identified as having a negative impact on the software. A library of metrics is also available to characterize software relative to expected models.

Readability: This audit objective locates programming constructs that affect local readability, are inconsistent, or, because of their complexity, make programs harder to understand and maintain.

Portability and Reusability: This audit objective locates constructs that are generally more portable and reusable. It can also provide specific suggestions to make a set of code more portable or reusable This analysis can be used to improve the general portability of software units or to avoid problems when the software is intended for another target compilation system.