Component evolution and maintenance

Figure D-6. Basic activities sequence for an individual build

Preliminary Design Walkthroughs

Initial prototyping and design work was concluded with a PDW and a basic capability demonstration. The walkthrough focused on the structural attributes of the components within the build. The basic agenda was tailored for each build, but it generally included the following topics for each CSCI:

• Overview: CSCI overview, interfaces, components, and metrics

• Components: walkthrough of each major component, showing its source code interface, allocated system requirements specification (SRS) requirements, current metrics, operational concept for key usage scenarios, standalone test plan, and erroneous conditions and responses

• Demonstration: focused on exercising the control interfaces across the components within the integrated architecture

Critical Design Walkthroughs

A build's design work was concluded with a CDW and a capability demonstration that exposed the key performance parameters of components within the build. While the PDW focused on the declarative view of the design, the CDW focused on the completeness of the components and the behavioral perspective of operating within the allocated performance requirements. The basic agenda was tailored for each build, but it generally included the following topics for each CSCI:

• CSCI overview: interfaces, components, and metrics; summary of changes since PDW; disposition of all PDW action items; build integration test scenarios

• Components: walkthrough of each major component, showing its source code interface, allocated SRS requirements, current metrics, operational concept for key usage scenarios, stand-alone test plan, and erroneous conditions and responses

• Demonstration: focused on exercising the critical performance threads Code Walkthroughs

Detailed code walkthroughs were also used to disseminate projectwide expertise and ensure the development of self-documenting source code. Some authors generated source code that demonstrated excellent levels of readability worthy of being assessed as self-documenting. The CSCI managers and the software chief engineer coordinated the need for code walkthroughs and their allocation among various authors to meet the following objectives:

• Better dissemination of self-documenting source code style

• Identification of coding issues not easily caught by compilers and source code analysis tools

• Object naming, coding style, and commenting style: Does it promote readability?

• Unnecessarily complex objects or methods: Are there simpler approaches?

• Reuse: Is custom software being built where reusable components exist?

• Potential performance issues: Are there potentially inefficient implementations?

• Reduction of the amount of source code needed for review in the larger design walkthroughs

• Exposure of inexperienced personnel to the products of experts and vice versa

The typical code review involved a single reviewer limited to two hours of detailed analysis using on-line source code browsing tools. The result of the review was confined to a one-page description of relevant comments to the author, the CSCI manager, and the software chief engineer. The software chief engineer was responsible for noting global trends, identifying improvements needed in code analysis tools, and raising lessons learned to the appropriate walkthrough or other technical exchange forum.

Turnover Reviews

Turnover reviews were not really reviews; they were typically a one-month activity during which components were completed with stand-alone testing and turned over for configuration control, build integration testing, and engineering string testing.

The checkpoints used on CCPDS-R for the incremental design process are good examples of the minor milestones described in Section 9.2. The mixture of walkthroughs and , inspections was focused on the 20% of components that had a potential high return | on human resource investment. In general, the real value of design walkthroughs and | inspections was communications among project subteams and methodical coordination of processes. Very few serious quality flaws were uncovered in these meetings (as opposed to the demonstration activities), but the technical interchange was well mechanized by these checkpoints.

D.5.3 Component Evolution

CCPDS-R used Ada as a uniform life-cycle format for design evolution. This uniformity allowed for software development progress metrics to be extracted directly from the evolving source files. The use of Ada as a design language was based on a special design package containing objects that had names prefixed by the string TBD (to be defined). This package of TBD objects included predefined TBD types, TBD constants, TBD values, and a TBD procedure for depicting source lines of code associated with comments that together would act as placeholders for as-yet undefined code segments. In particular, there was the following procedure declaration:

TBD_Statements (Number_Of_Statements: In Integer);

This declaration required that a parameter depict the number of statements estimated for a given code segment described with proper comments. Source lines with calls to a TBD object were counted as ADL (Ada design language) lines; source lines with no TBD references were counted as Ada source lines. Table D-2 provides an example of a typical component evolution.

The basic component evolution would look like this:

• At creation, only the interface (the specification part) would be defined with Ada source lines and corresponding comments. The estimated SLOC count for the component would typically be specified by a single

TBD_Statements line.

• At PDW, the substructure of the component would be fleshed out along with most component declarations and estimates of the subordinate program units using multiple calls to TBD_Statements. At this time, there would generally be about 30% of the SLOC in Ada and 70% in ADL.

• By CDW, most of the program unit interfaces and declarations would be fully fleshed out in Ada, with some detailed processing still using TBD_statements as placeholders. In general, CDW-level components would be about 70% Ada and 30% ADL. A guideline also stated that by CDW, there would be no calls to TBD_statements with values greater than 25.

• By turnover, the string TBD would not appear anywhere in the source files. This would correspond to a complete implementation.

Table D-2. A typical component evolution from creation through turnover

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