These guidelines were violated occasionally, but the evolution of most components followed this pattern pretty well. There were also detailed style standards that formed the basis of early code walkthroughs and the requirements for an automated code auditor that checked for numerous standards violations before turnover.

One of the by-products of the use of Ada as a design language for CCPDS-R was that the evolving source files were always in a uniform representation format from which the current work accomplished (source lines of Ada) and the current work pending (TBD_statements) could be easily extracted. Although the Ada source lines were not necessarily complete—inasmuch as further design evolution might cause change—they represented a relatively accurate assessment of work accomplished. The complete set of design files across the development teams could be processed at any time to gain insight into development progress. A metrics tool was developed that scanned Ada source files and compiled statistics on the amount of completed Ada and TBD_statements. It produced outputs such as those listed in Table D-3.

This metrics tool and the CCPDS-R coding standards allowed collection of metrics by CSCI and by build so that progress could be monitored from several perspectives. The development progress metrics described in Section D.7.1 were derived monthly from the outputs of this tool and were presented at the various design walkthroughs by each component designer to display the summary metrics and hierarchy of the component being discussed.

This metrics tool allowed management to extract some key measures of progress directly from the evolving source baselines. The software engineers simply adhered to the software standards in fleshing out their source files and maintaining them in compilable formats. Once a month, all source code was processed by the tools and integrated into various perspectives for communicating progress. The resulting metrics were useful not only to the managers but also to the engineers for communicating why they needed more resources or why they needed to reprioritize certain activities. As described in Chapter 13, acceptance by both manager and practitioner, and extraction directly from the evolving artifacts, were crucial to the success of this metrics approach.

Table D-3. NAS CSCI metrics summary at month 10


Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment