Preceding sections of this case study have described specific approaches and metrics. This section summarizes some other, more global perspectives of CCPDS-R project performance: software size evolution, subsystem process improvements, SCO resolution profile, and CSCI productivities and quality factors.
The software sizes of the Common Subsystem and the individual CSCIs were tracked monthly and were derived directly from the evolving metrics files. There was a large amount of code growth from the original contract bid (150,000 SLOC) to the delivered product (355,000 SLOC), with no substantial increase in the software development budget. There were two reasons for this level of code growth:
1. The method for counting source lines was changed around month 8 to provide a better balance in estimating the engineering effort and to be consistent with the counting method embraced by Ada COCOMO.
2. Several automatic code generation tools were developed that output verbose source code with fewer human-generated input lines. These tools were used for the straightforward generation of display formats, message validation processing, and socket/circuit bookkeeping functions. They represented about 14,000 SLOC of tools, which required another 20,000 lines d.8 other metrics 349
of input data files. The output of these tools was about 200,000 SLOC of operational software. In gross terms, these code generation tools resulted in about a fivefold return on investment.
The primary reason for the increase in SLOC was the change in the counting rules. At contract award, a simple semicolon count was being used. This approach transitioned to the following counting procedure, which was implemented with a simple tool used by all personnel on the project:
• Within an Ada specification part, each carriage return counted as one SLOC. Four coding standards allowed the SLOC counting to be consistent:
1. Each parameter of a subprogram declaration is listed on a separate line. The effort associated with design of a subprogram interface is generally proportional to the number of parameters.
2. For custom enumeration types (such as socket names and system states) and record types, each enumeration or field is listed on a separate line. Custom types usually involve custom design and engineering, resulting in an increased number of SLOC.
3. For predefined enumeration types (such as keyboard keys and compass directions), enumerations are listed on the fewest number of lines possible without loss of readability. These types generally require no custom engineering.
4. Initialization of composite objects (such as records and arrays) is listed with one component per line. Each of these assignments represents a custom statement; an "others" clause is typically used for noncustom assignments.
Was this article helpful?
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.