CCPDS-R A Case StudylAn objective case study is a true indicator of a mature organization and a mature project process. The software industry needs more case studies like CCPDS-RlThe metrics histories were all derived directly from the artifacts of the projects process. These data were used to manage the project and were embraced by practitioners, managers, and stakeholderslCCPDS-R was one of the pioneering projects that practiced many modern management approachesCCPDS-R A Case StudylA detailed case study of a successful software projectlSuccessful means on budget, on schedule, and satisfactory to the customerlCommand Center Processing and Display System-Replacement projectlFor the U.S. Air Force, from 1987 to 1994, by TRW, Ca.lIncluding system engineering, hardware procurement, and software development, each consuming about 1/3 of the total costlThe software effort included the development of three distinct software systems totaling more than one million source lines of code, and each consuming about 1/3lThe case focusing on the initial software developmentCommon Subsystem, about 355,000 source lines, producing a reusable architecture, a mature process, and an integrated environment for other two subsystemsCCPDS-R A Case StudyCD: Concept Definition FSD: Full-Scale Development like inception phaseCCPDS-R A Case StudylA very large software development activitylUsing Ada languagelThe purpose of the SE exercise be to demonstrate that the contractors proposed software process, Ada environment, and software team were in place, were mature, and were demonstrablelConduct a mock design review with the customer 23 days after receipt of a simple two-page specification of a “missile warning simulator” lTRWs CCPDS-R team won (12 people for 23 days)CCPDS-R A Case StudyThe following results were produced with the proposed software development plan:CCPDS-R A Case StudylTRW proposing an architecture-first, demonstration-based approachlMore than 20% bid higher than that of their competitorlThe best value and lowest risklSuccessful performance on the SE exerciselAbility to demonstrate their process under realistic conditionsCCPDS-R A Case StudylThe primary responsibilities of the CD phase team:CCPDS-R A Case StudylThe six computer software configuration items(CSCIs) of the Common Subsystem softwareCCPDS-R A Case StudyCCPDS-R A Case StudyCCPDS-R A Case StudylIn the CCPDS-R definition of an architecture, the view of the Software Architecture Skeleton(SAS) included the followingCCPDS-R A Case StudylTwo important aspects of SAS verification and assessment: compilation and executionlThe SAS provides the forum for integration and architecture evolution. It is important to construct the SAS early and to evolve it into a stable baselinelCCPDS-R installed its first SAS baseline (after three informal iterations) around month 13,just before the PDR milestonelAll subsequent change was performed via rigorous configuration controllThe SAS was useful in assessing the volatility in the overall software interfaces and captured the conceptual architecture of the Common SubsystemCCPDS-R A Case StudyCCPDS-R A Case StudyThe software architecture stability with Common Subsystem SAS evolution From a macroprocess view, the initial milestones focused on achieving a baseline architecture. The PDR baseline required three major architecture iterations, the conclusions of which coincided with the milestones for the software requirements review (SRR), interim PDR (IPDR), and PDR:The SRR demonstration: initial feasibility of the foundation components, and basic use cases of initialization and interprocess communicationsThe IPDR demonstration: the feasibility of the architectural infrastructure under the riskiest use cases, including the following:The PDR demonstration: adequate achievement of the peak load scenarios and the other primary use cases within a full-scale architectural infrastructure, including the other critical-thread componentsThe CDR demonstration updated the architecture baseline to represent the equivalent of an alpha test capability for the complete architectural infrastructure and the critical-thread scenarios. This was a usable system in that it provided a set of complete use cases sufficient for the user to perform a subset of the mission.A peak data load missile warning scenario of a mass raid from the Soviet UnionA peak control load scenario of a system failover and recovery from the primary thread of processing to a backup thread of processing with no loss of dataCCPDS-R A Case Study- Process OverviewBuild 0. This build comprised the foundation components necessary to build a software architecture skeleton. The intertask/interprocess communications, generic task and process executives, and common error reporting components were included. This build was also the conclusion of the research and development project executed in parallel with the CD (inception) phase. These NAS components were the cornerstone of the architectural framework and were built to be reusable across all three CCPDS-R sub-systems. They represented very complex, high-risk components with stringent performance, reliability, and reusability demands. The Details of the Build ContentBuild 1. This build was essentially the architecture. It included a complete set of instantiated tasks (300), processes (70), interconnections (1,000), states, and state transitions for the structural solution of the CCPDS-R software architecture. To achieve a cycling architecture, this build also added all the NAS components for initialization, state management (reconfiguration), and instrumentation. A trivial user interface and the capability to inject test scenarios into the architecture were added to support the initial demonstration. Upon completion of build 1, only a few critical use cases were demonstrable: initializing the architecture, injecting a scenario to drive the data flow through the system, and orchestrating reconfigurations such as primary thread switchover to backup thread.The Details of the Build ContentBuild 2. This was the first build of mission-critical components and achieved the initial capability to execute real mission scenarios. The three primary risks inherent in the mission scenarios were the timeliness of the display database distribution, the performance (resource consumption and accuracy) of the missile warning radar algorithms, and the performance of the user interface for several complex displays. Upon completion of build 2, several mission-oriented use cases could be executed, including the worst-case data processing thread and the worst-case control processing thread (primary-to-backup switchover).The Details of the Build ContentBuild 3. This build contained the largest volume of code, including display format definitions, global type definitions, and representation specifications needed for validation of external interface transactions. Although the code was voluminous, much of it was produced automatically in a cook-book manner by constructing code generation tools. The remaining components allocated to build 3 included the external communications interface protocol handling, the completed user-system interface for the mission operators, the user-system interface for the computer support positions, the system services for mission reconfigurations, database resets, off-line data reduction, and the nuclear detonation algorithms. Although initially planned as one large build, this increment was later split into two more manageable releases, builds 3-1 and 3-2.The Details of the Build ContentBuild 4. This build provided the final installment of missile warning algorithms for satellite early warning systems, the final installment of mission management and mission status displays, and the final installment of external communications interface processing.Build 5. In the middle of the Common Subsystem schedule, build 5 was added to coincide with a particular external interface (being built on a separate contract), the schedule for which had slipped so that it was not going to be available during its originally planned build (build 4). Consequently, the external interface was scheduled into an entirely new build.The Details of the Build ContentThe individual milestones within a build : preliminary design walkthrough(PDW) critical design walkthrough (CDW) turnover review (TOR) CCPDS-R A Case Study- Process OverviewCCPDS-R A Case Study- Process OverviewPreliminary 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 metricsComponents: 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 responsesDemonstration: focused on exercising the control interfaces across the components within the integrated architectureCCPDS-R A Case Study- Process OverviewCritical Design Walkthroughs A builds 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 scenariosComponents: 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 responsesDemonstration: focused on exercising the critical performance threadsCCPDS-R A Case Study- Process OverviewCode WalkthroughsDetailed 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 versaCCPDS-R A Case Study- Process OverviewTurnover ReviewsTurnover 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.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 procedureCOMPONENT 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.