CCPDS-R software development was required to comply with DOD-STD-2167A, which is now obsolete. Without going into detail about the documentation required, this section summarizes the basic documentation approach used on the project. Data item descriptions in 2167A specified document format and content. Substantial tailoring was allowed to match the development approach and to accommodate the use of Ada both as a design language and the implementation language. Primary tailoring included the following:
1. Use of the evolving Ada source files as the single homogeneous life-cycle design format and evolution of these files in a self-documenting manner. This technique exploited Ada's readability features and avoided the extra effort involved in preparing separate, detailed design descriptions that inevitably diverge from the implementation.
2. Organization of the test sequences and deliverable documents around the build content driven by subsets of use cases (referred to as engineering strings and scenarios) rather than by CSCI. This string-based testing spanned components in multiple CSCIs. It was organized by build and mechanized via a software test plan, software test procedure, and software test report documentation sequence. These document sequences were provided for each BIT (one for each build), each EST (for builds 2, 3, and 4), and FQT (one final all-encompassing test sequence). Each test sequence involved components from several (incomplete) CSCIs because integration was proceeding continuously.
3. Building of separate unit test documentation as self-documented, repeat-able software. This was treated like other operational source code so that it was maintained homogeneously and up-to-date for automated regression testing. The same concept was used for the BIT and EST scenario testing: Rather than develop test procedure documents, the CCPDS-R process generated self-documenting test scenarios that were software programs in their own right. Because they were subjected to change management just like other software, they were always maintained up-to-date for automated regression testing.
Table D-4 summarizes the software documentation that resulted from 2167A tailoring and the corresponding artifacts recommended in Chapter 6. The 2167A approach was tremendously inefficient, even with tailoring (although it was far more efficient than the approach used for most conventional projects). It was clear from the outset that the documentation burden was tremendous, but straying from convention was considered too risky. Table D-4 focuses only on software documentation, excluding documents that supported the systems engineering concerns (safety, human factors engineering, reliability) and the operational community (cutover plan, logistical support, training). Those documents also required input and support from the software organization, even though the primary responsibility for them resided elsewhere within the CCPDS-R project.
One of the key artifacts in Table D-4 is the software development file (SDF). For CCPDS-R, this was an organized directory of on-line information, rather than a document, most of which was maintained as compilable, self-documenting Ada source code. The SDF had several sections of content that evolved as described in Table D-5.
CCPDS-R evolved an approach to artifacts that is very similar to the approach presented in Chapter 6. Initially, most artifacts were paper-based. After the customer showed far more interest in the demonstration artifacts and the configuration baselines of the product components and test components, the demand for paper documents subsided—not enough, but somewhat. One big improvement was the transition to a completely electronic SDF, in which the design and coding standards promoted self-documenting artifacts. Separate artifacts to document the design and code were no longer necessary. One long-standing issue for CCPDS-R was the need for a higher level, graphical design description. This was provided in the system design document and in software top-level design documents using ad hoc text and graphics to represent the design. These representations were ambiguous, frequently out of date, and difficult to understand. The use of Unified Modeling Language notation, an architecture approach such as that presented in Chapter 7, visual modeling tools, and support for round-trip engineering would have improved the design representation approach considerably and would have eliminated a lot of wasted effort.
d.5 process overview 325
artifact counterpart (chapter 6)
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.