Effective software engineering techniques are needed to increase the reliability of software systems, to increase the productivity of development teams, and to reduce the costs of software development. Organizations search for an effective software engineering process as they strive to reach higher process maturity levels, produce better software, and win new contracts. To aid in this search for better methods of software engineering, the Software Engineering Research Center's (SERC) Design Metrics Research Team at Ball State University has analyzed university and industry software to be able to correctly identify error-prone units during the design phase of software development. The research team has developed and tested their design metrics De, Di and D(G)over a six-year period and has found them to be excellent predictors of error-prone units.
The Design Metrics Analyzer for C (DMAC) has been developed to automate metrics collection and calculation of C systems. This tool improves the metrics collection by ensuring the accuracy of metrics calculation and by minimizing the interference with the existing work load of a software engineer. The DMAC collects 65 metrics, including the Zage design metrics, De, Di and D(G), LOC, limited terminal semicolon count, comments, embedded comments, V(G) and other primitive syntactical constructs on each C function. DMAC also provides a complete design metrics analysis. This proven technology yields a list of stress points, which are units that are considered to be error-prone or difficult for developers. This analysis is performed at the function level. A set analysis is also performed in which units identified as stress points by one, two or all three of the design metrics, De, Di and D(G) are grouped into sets. Managers or developers can investigate which units were flagged by all three metrics. This total analysis assists software engineers in determining which components in a system need to be reexamined. This analysis also can be completed on any of the metrics that the tool collects.
Since the DMAC can accept partial systems and since the input files to the DMAC may be disconnected subsets of a system, the DMAC also performs a connectivity analysis. The connectivity report identifies the number of subsystems and the number of modules contained in each subsystem. This analysis can also identify redundant modules and dead code.
From the given input, the DMAC also generates a variety of content reports. The content information reports that are produced are named unit information, files analyzed, call structure, call index, and variable table. The unit information report is a textual summary of information available about each function. For example, this report contains a listing of local variables declared and global variables used, including the original declaration and location. The parentage of a variable is identified for the developer or maintainer. The unit information report also lists the fan-in (called_by) and fan-out (calls) of each function. To determine which files were included in an execution of the tool, the files analyzed report would be reviewed. Also included here is a LOC count for each file. The call structure report textually reproduces the calling structure of the modules contained in the submitted files. Each page of the report identifies the subsystem and the root module. The call index report, a companion to the call structure report, is an alphabetized index of each module location in the call structure report. The variable table report contains all variables, their type, location of their declaration, and the list of modules which access and/or modify it. These reports provide developers with detailed, specific information about the system submitted to the DMAC.
DMAC executes on the Unix platform.