Software Development Guide

NOAA National Environmental Satellite, Data, and Information Service (NESDIS) Comprehensive Large Array-data Stewardship System (CLASS) Software Development Guide CLASS-1002-CLS-PRO-Guide March 15, 2005 CLASS Project Software Development Guide Revisions Version Draft V1 1.0 1.1 1.2 1.3 1.4 1.5 1.5 1.5 2.0 Description of Version Initial draft Incorporated CPMT input – approved by CPMT Reformatted to extract procedures to separate documents Incorporated QA review comments – approved by PM New organization incorporated SEPG comments incorporated Incorporated SEPG review comments Incorporate planning clarification Approved by CPMT; changed release number upon approval. Version changed to reflect CPMT approval. Date Completed 7/22/02 10/01/02 07/17/03 09/02/03 9/30/03 10/17/03 9/30/04 01/17/05 03/15/05 03/15/05 CLASS-1002-CLS-PRO-Guide Page i CLASS Project Software Development Guide Review & Approval Software Development Guide Review History Reviewer SEPG CPMT Version Reviewed 1.5 1.5 Approval Date 02/09/05 03/15/05 CLASS-1002-CLS-PRO-Guide Page ii CLASS Project Software Development Guide Table of Contents 1 Introduction ............................................................................................................................... 1 1.1 General Development Approach ............................................................................................... 1 1.2 Project Organization................................................................................................................... 2 1.3 Development Environment ........................................................................................................ 3 1.4 Related Documents .................................................................................................................... 3 1.5 Document Maintenance ............................................................................................................. 4 2 Release Planning...................................................................................................................... 5 2.1 Scope Definition ......................................................................................................................... 6 2.2 Effort Estimate............................................................................................................................ 7 2.3 Release Schedule ........................................................................................................................ 8 3 Software Development Process .......................................................................................... 9 3.1 Process Overview ....................................................................................................................... 9 3.2 Design Goals ............................................................................................................................. 12 3.3 Coding Standards ..................................................................................................................... 14 4 Independent Testing Approach ......................................................................................... 15 4.1 Levels of Testing ...................................................................................................................... 15 4.2 Test Documentation ................................................................................................................. 15 4.3 Problem Tracking ..................................................................................................................... 15 5 Software Documentation Standards ................................................................................ 17 5.1 Software Design Documentation............................................................................................. 17 5.2 Software Description ................................................................................................................ 18 5.3 Configuration Change Requests .............................................................................................. 19 5.4 Problem Reports ....................................................................................................................... 19 5.5 Work Requests.......................................................................................................................... 19 6 Metrics Collection ................................................................................................................. 20 6.1 Peer Review Records ............................................................................................................... 20 6.2 Release Folders ......................................................................................................................... 20 6.3 Organizational Data Collection ............................................................................................... 20 Appendix A – Critical Computer Resources ........................................................................ 21 Appendix B – Acronyms ............................................................................................................. 22 CLASS-1002-CLS-PRO-Guide Page iii CLASS Project Software Development Guide Table of Figures Figure 1 - Release Life Cycle .............................................................................................................. 2 Figure 2 - CLASS Project Organization ............................................................................................. 2 Figure 3 - CLASS Technical Environments ....................................................................................... 3 Figure 4 - Development Process ........................................................................................................ 10 CLASS-1002-CLS-PRO-Guide Page iv CLASS Project Software Development Guide 1 Introduction This software development guide describes the approach and processes to be followed throughout the development of the Comprehensive Large Array-data Stewardship System (CLASS). The CLASS development project includes several separate development groups from different organizations and different geographic areas. To ensure consistent quality and compatibility of the various components of CLASS developed by this distributed team, all members of the CLASS development team will follow the standards and procedures described here. The CLASS Quality Management (QM) personnel will provide oversight and guidance for all development groups in the application of the CLASS processes, as defined in the CLASS QM Plan. This section of the guide describes the overall development environment for CLASS, including organization and baseline documents. Subsequent sections describe the processes, standards, and procedures for release planning, development (detailed design and coding), testing, documentation, and metrics. Appendix A summarizes the approach for assessing and updating the hardware platforms that support the software. This document will be updated throughout the development life of CLASS to incorporate lessons learned and process improvements. The CLASS Project Management Team (CPMT) approves any updates to this document. Once approved, updates will be distributed to all members of the CLASS development team and posted in the CLASS online library. 1.1 General Development Approach The overall goal for CLASS is to provide one place for access to all NOAA/NESDIS data. Specifically, CLASS is currently scheduled to support data archiving and retrieval for seven major campaigns over the next several years (see the CLASS Master Project Management Plan for a project overview). To meet these goals in a cost-efficient manner, CLASS is being developed in an evolutionary manner, re-using existing system functionality as possible. The data archive and distribution functionality is based on the Satellite Active Archive (SAA) system, which was developed to support NOAA Polar-orbiting Operational Environmental Satellites. The overall methodology used in the development of CLASS is iterative and release-based. The iterative approach allows for the continued refinement of detailed requirements and design as new campaign requirements are defined. Implementation is release-based in order to minimize risk to the operational baseline as the system evolves. CLASS-1002-CLS-PRO-Guide Page 1 CLASS Project Software Development Guide Figure 1 shows the high-level process flow for the release life cycle. Release Planning Design & Code System Integration & Test Promote to Operations Planning for Future Releases Figure 1 - Release Life Cycle 1.2 Project Organization The CLASS project is distributed across several development groups that are organizationally and geographically distinct. Figure 2 shows the project development-related organization. The project is managed by a joint project management team (the CPMT) and by a common set of baseline documents, standards, and processes. The roles and responsibilities of key team members are defined in the CLASS Master Project Management Plan. The CLASS System Engineering Team (SET) includes representatives from each development group and coordinates the technical direction for CLASS as defined in the SET charter. The Configuration Control Board (CCB) controls changes to the CLASS baselines, as described in the CLASS Configuration Management Plan. See Section 1.3, Development Environment, for CLASS operations environments. CLASS Archive Requirements Working Group CCB SET CPMT CMO NESDIS OSD Project Manager OSDPD Development Team (Suitland, MD) NCDC Development Team (Fairmont, WV) NGDC Development Teams (Boulder, CO) System Integration & Test Team (Suitland, MD) Figure 2 - CLASS Project Organization CLASS-1002-CLS-PRO-Guide Page 2 CLASS Project Software Development Guide 1.3 Development Environment Each development group maintains a local development environment for coding and unit and component integration testing. A common source code control system provides the baseline code for CLASS. When a component has been developed and tested locally, it is then turned over to the system integration and test team for integration into the CLASS test environment. Figure 3 shows the overall flow of software changes within the CLASS project. Details of each step are defined in later sections of this guide. Promotion of the software through this path is described in the Software Change Promotion Procedure. Suitland Development Environment West Virginia Development Environment Integration Environment Suitland Test Environment Operational Environment (Suitland) Operational Environment (Asheville) Boulder Development Environment Deployment Test Environment Figure 3 - CLASS Technical Environments 1.4 Related Documents All CLASS baseline documents are stored in the CLASS document repository. These include the following documents:        Configuration Management Plan, CLASS-1001-CLS-PLN-CM Quality Management Plan, CLASS-1006-CLS-PLN-QM Master Project Management Plan, CLASS-1028-CLS-PLN-MPMP CLASS-MD Activity Plan, CLASS-1003-CLS-PLN-CSDPC CLASS-WV Activity Plan, CLASS-1073-CLS-PLN-TMCAP CLASS Procedures, available in the CLASS document repository under Baseline Documentation>Procedures CLASS technical baseline documents, available in the CLASS document repository under Baseline Documentation>Technical>Approved Documents The following documents are available in the CLASS online library at: http://library.class.noaa.gov/.  Software Description documentation CLASS-1002-CLS-PRO-Guide Page 3 CLASS Project    Software Development Guide Software Standards for Information Processing Division (IPD), June 30, 2001 CLASS-MD status documentation CLASS promotion reports Additional local procedures for each participating organization may be stored in local document repositories. 1.5 Document Maintenance This Software Development Guide (SDG) is baselined and approved by the CLASS Software Engineering Process Group (SEPG), then the CLASS Project Management Team (CPMT). Any proposed changes to this document will be presented to the CLASS Process Manager as a new Work Request (WR) in accordance with the process defined in the CLASS Work Request (WR) procedure and the CLASS Process Baseline Document Management procedure. During the course of the project, this document will be reviewed for accuracy and updated on a yearly cycle to reflect process improvements. CLASS-1002-CLS-PRO-Guide Page 4 CLASS Project Software Development Guide 2 Release Planning The success of the release-based approach is largely determined during the release planning effort. The CPMT must allocate requirements to each release in a manner that    Addresses campaign needs and schedules Groups related design and code changes so as to minimize code disturbance Provides for maximum generalization of functionality The major activities that take place during release planning are described in this section. These activities may be iterative during the course of defining a release: an initial set of requirements is allocated to the release, the effort for implementation is estimated, and the resulting schedule for delivery is determined. If the resulting schedule is not acceptable, the requirements allocation is revisited to change the scope of the release to one that can be completed in the required timeframe, or the resources allocated to the release are increased to meet the target completion date. At a high level, release planning and monitoring are conducted as follows: Release planning on CLASS: Release planning determines the number of CCRs that are calculated for each release. The following three components are used to plan the number of CCRs for a release based on the allowed timeframe and available resources  Fiscal Year (FY) Basis of Estimate (BOE)  Schedule  Resources The TALs calculate the number of CCRs that can be included in a release by calculating the current BOE against the number of available resources in the planned timeframe, e.g., BOE of 20 days/CCR x Schedule of 3 months x available Resources of 15 staff. The release planning shows 45 CCRs can be completed in the schedule timeframe (not considering test timeframe). At this point, the TALs review the CCRs already assigned to the release for comparison with the plan. The TALs then consider the priority of the CCRs, as high priority CCRs will take more time to complete than low priority CCRs (as a guideline, BOE represents High priority CCRs, ½ BOE represents a Medium priority CCR, and ¼ BOE represents a Low priority CCR). The TALs balance the release contents considering the priority, and the functionality focus of the CCRs. Release Monitoring on CLASS: Release monitoring balances the release workload. Progress is considered against the schedule through status reports and status meetings. The TALs again consider the available schedule to completion for the release, the number of resources and their progress, as well as the remaining CCRs assigned for the release. The TALs, at this point, may determine more CCRs could be added to the release, or calculate the assigned CCRs for the release will not be completed in the planned timeframe. The TAL will determine any CCRs that could be removed from the release or determine if the release schedule will need to be extended. All decisions are shared with the CPMT membership. CLASS-1002-CLS-PRO-Guide Page 5 CLASS Project Release Control on CLASS: Software Development Guide Configuration control ensures formal disposition of modified CCR release assignments. As part of release monitoring, any CCRs recommended for change to a different release are presented to the CCB for approval. These CCRs disposed at the next CCB meeting. The following sections provide more description on the scope definition, effort estimation, and release scheduling for CLASS. 2.1 Scope Definition CLASS system (Level I CCRs from the OSD Project Manager) and allocated (Level II CCRs from the CPMT) requirements are maintained in the CLASS requirements repository. Associated with each allocated requirement are the source (campaign or other source) and the required operational date or release. The CLASS CM plan, the Requirements Management Procedure, and the Configuration Change procedure describe the processes for managing all levels of new or proposed requirements. Near the end of development of a release, the CPMT, SET, and development leads begin assessment of the scope for the next releases:     Major drivers for the release are defined based on upcoming external commitments (e.g., new campaigns) and project goals defined in the annual plan. CCRs are disposed according to the annual plan Existing Level III configuration change requests (CCRs) are reviewed to verify the assignment to their release. (See the CLASS CMP for descriptions of the CCR levels.) Requirements assigned to the release time period are reviewed and validated to determine if the release content is still desirable. Validation includes: o Related requirements comprising a single functional capability are grouped together. Each group should include only requirements that are so tightly coupled that it is not reasonable to implement one without concurrently implementing all in the group. o All requirements not implemented yet are reviewed to determine if any are logically related to those groups planned for this release. If any are identified, they are added to the appropriate grouping. o A Level III CCR is created for each proposed functional change, and entered into the CLASS change management tool, if a Level III CCR does not exist. All changes are documented in CCRs before implementation begins to facilitate tracking of the change status (to include in a functional release). The release scope includes the CCRs defining new capabilities to be implemented and existing problems to be corrected in the release. The Technical Area Lead (TAL) constructs a release list, which is then reviewed by the CPMT for consistency with current priorities. The list is then assessed for effort and schedule, as described in the following sections, and revisited as necessary. When all parties – development groups, test team, and management – are satisfied that the work can be completed in the desired timeframe, with acceptable quality, the release CLASS-1002-CLS-PRO-Guide Page 6 CLASS Project Software Development Guide scope is documented by the list of allocated CCRs. The NOAA CLASS Technical Lead has final authority on release content. Any changes to scope (i.e., inclusion of additional CCRs or elimination of CCRs) proposed by the development groups during the release implementation must be reviewed by the integration test team and approved by the NOAA CLASS Technical Lead at the CCB. 2.2 Effort Estimate In order to meet the CLASS schedule and quality commitments, accurate effort estimates are a key input to the release planning activity. The accuracy of software estimates is driven by two key considerations:   The level of detail of understanding of the requirement to be implemented or problem to be corrected, and The historical organizational experience with similar implementation efforts (similar in application, platform, programming language, etc.) The level of detail of understanding changes during the system life cycle. Initial effort estimates, for development and test, are less accurate than those derived after detailed design is completed. Development and test estimates are reviewed at least twice during a release, and more frequently as warranted: once at initial release planning, and once the release contents are assigned. The initial release plan should include schedule contingency based on expected changes in the effort estimate after design. Estimates used for release planning for each CCR may originate from either of the following:    The TAL uses fiscal BOEs to determine the number of CCRs that can be completed within the planned release timeframe with the number of available resources. If the CCR Analysis Information has been completed, the TAL may use the effort estimate provided in that section of the CCR. If the CCR Analysis Information has not been completed, the TAL uses the effort estimate associated with the effort level provided by the system engineer as the initial assessment. This default estimate is calculated after each release, based on actual effort, and documented in the release report. The system engineer provides a preliminary effort level (High, Medium, Low) for each CCR when it is received, as defined in the CLASS CCR Procedure. Each development group is responsible for reviewing and refining the estimates for CCRs assigned to their group, during the release planning phase. If changes in estimates later in the release suggest the schedule will not be met, the CPMT reviews the release scope and schedule to determine if the schedule should be adjusted, the scope revised, or additional resources applied. CLASS-1002-CLS-PRO-Guide Page 7 CLASS Project Software Development Guide 2.3 Release Schedule Each Technical Area Lead (TAL) prepares a detailed plan for their part of the release, based on input from the development group. This plan includes all tasks, milestones for each task, resources assigned to each task, and dependencies between tasks as defined by OSD Project Management in NOAA NESDIS campaigns. The tasks are categorized according to the CLASS Work Breakdown Structure (WBS), and the work defined using a standard Earned Value Method, as documented in the CLASS Project Management Plan and the Cost and Schedule Tracking Procedure. The following types of development activities should be included in the release plan:  Initial analysis, design, code, and development testing  Review of design, code, test plans, test results, and documentation  Rework, for problems found during the integration and test phase  Documentation Integration and system test tasks include  Test planning  System builds  Test execution  Retesting of software where problems were found in initial testing  Documentation of test results If there are dependencies on the order in which new capabilities are tested, these must be defined in the release plan. Plans should also include allocation of effort (both development and system testing) for analysis of new CCRs received during the release period. The CPMT reviews the release plans, including the critical path for each development team and dependencies between the teams. The CPMT reviews progress of the release at each meeting, with particular attention to release drivers (defined in Section 2.1), critical path activities, and inter-group dependencies. The CPMT manages risks associated with critical dependencies as described in the CLASS Risk Management Procedure. The responsible TAL, in consultation with appropriate NOAA personnel, may add or remove non-critical content from the release, with final disposition by the CCB. The CPMT reviews any change affecting delivery of release drivers or critical dependencies. CLASS-1002-CLS-PRO-Guide Page 8 CLASS Project Software Development Guide 3 Software Development Process After the scope of the release has been defined by the CPMT and approved by the NOAA CLASS Technical Lead, each CCR is assigned to a developer for implementation. Development activities include:      Requirements analysis to ensure the requirement or problem is understood Detailed design to define the implementation approach Coding of the new or changed functionality Unit and component testing of the new or changed code Peer review After the development group has tested the function, it is turned over to the CMO for promotion to the integration and test environments, for integration into CLASS and formal testing. This section describes the process and procedures for the development activities, including design and coding standards for CLASS development. Independent integration and testing activities are addressed in Section 4. 3.1 Process Overview Figure 4 shows the process flow for development activities, from initiation of work on a CCR to turnover to CM for independent integration and test. In order to identify and correct problems as early in the development process as possible, the CLASS project uses a series of peer reviews as each function is implemented. This section describes the steps in the development process, including the points where peer review is conducted. These same steps remain in effect for developers working on Problem Reports (PRs). Where reference is made to a CCR, the same steps equally apply to PR resolution. Details for development activities are provided in the following CLASS procedures:      The CCR Procedure describes the status and supervisor assignment for a CCR throughout the life-cycle The Source Code Control Procedure describes the procedures for moving code in and out of the source code library The Peer Review Procedure describes the different types of peer review and includes the checklists for use in each review The Database Configuration Management Procedure describes the method for making changes to the CLASS database The Problem Reports Procedure describes the steps for correction of errors found during the integration and system testing cycles Developers should refer to the Baseline Documentation folder of the CLASS document repository and additional local processes and procedures for a comprehensive list of approved procedures. CLASS-1002-CLS-PRO-Guide Page 9 CLASS Project Software Development Guide Initiation Function Level Requirements Analysis & Design Design Peer Review Code Code Peer Review Code Peer Review ... Code Peer Review Unit Test Unit Test Unit Test Developer Integration Testing Documentation Development Testing Test Readiness Peer Review Turnover to CM Figure 4 - Development Process CLASS-1002-CLS-PRO-Guide Page 10 CLASS Project Software Development Guide Initiation The process is initiated when the software development lead assigns a CCR to a developer. Based on the complexity of the CCR, the software development lead designates the level of peer review required for that CCR, and identifies peer reviewers. For large, complex, or critical CCRs, a formal Work Product Inspection (WPI) may be required at the completion of design, and group reviews required for code and test. For minor changes to the code (e.g., correcting an error in a single line of code), only a one-on-one review at the completion of developer testing may be required. The vast majority of peer reviews conducted are one-on-one reviews. While the design and code peer reviews are optional at the discretion of the development lead, all CCRs and PRs require test readiness reviews prior to handoff to the CMO for integration. Function Level Requirements Analysis and Design When the assigned developer begins work on the CCR analysis, the developer reviews the CCR and gets clarification on any requirements. The developer then develops a detailed design for implementation, including identifying any new or modified code, user interface changes, and other interface changes. The developer re-estimates the effort required for implementation. If the effort estimate is significantly higher than the original estimate developed during release planning, the developer notifies the software development lead, so the CPMT can determine if the effort should remain included in the current release and if additional resources are required. When the developer has completed analysis of the requirements and design, and is ready to begin coding, the developer coordinates the design peer review, if defined during initiation. Any problems identified during the peer review are recorded and corrected before coding begins. Code After the design is complete, including peer review if required, the developer begins coding. Coding standards for the languages used in CLASS are discussed in Section 3.3 of this guide. The developer checks out the modules to be modified, completes coding for new or modified modules, and ensures a clean compile. The procedure for checkout and commit of source code changes is defined in the Source Code Control Procedure. The developer also completes planning for development testing at this phase. If a code review is required, the developer completes test planning and may conduct some preliminary unit testing prior to the peer review, but should not complete full testing. Conducting testing prior to the review delays the review, and results in rework when testing needs to be repeated after problems are found during the review. The peer reviewer reviews the development test plan as part of the code review. For large or complex functions involving many new or modified modules, the developer may complete a subset of the modules and schedule a peer review for that subset. The developer repeats this cycle for each subset until all modules are reviewed. The scope of an individual review should be small enough to be conducted in one or two hours, and large enough to include closely related modules. CLASS-1002-CLS-PRO-Guide Page 11 CLASS Project Software Development Guide Any problems identified during the peer review are recorded and corrected before the reviewer signs off on the review. Development Testing Developers conduct two levels of testing for each CCR: unit testing of each new or changed module, and development integration of the completed CCR. The developer prepares the plans for development testing during the Coding phase, specifying any test routines and test data needed. The developer should complete as much testing as possible before committing the changes into the source code control system. Each night, the development system is rebuilt incorporating all new committed changes for that day. This nightly build provides the foundation for all development testing across the project. Developers should ensure all code compiles and builds cleanly in their local environment before committing the changes to the controlled library. The developer conducts final development testing after the nightly build has integrated the changes into the development configuration. During the development test period, the developer also reviews any documentation related to the change and updates documentation as necessary, including completing implementation information on the CCR. Section 5 addresses documentation standards. At the completion of development integration, a final test readiness peer review is conducted to verify successful completion of the testing and documentation. This review certifies the software is ready for the independent integration and test team. Any problems identified during the peer review are recorded and corrected before the software is turned over. When the test readiness peer review is complete, the developer updates the CCR and notifies the software development lead the software is ready for turnover. The software development lead verifies all peer reviews have been completed and all metrics have been captured, and reassigns the CCR to the CMO for promotion to Integration. 3.2 Design Goals Maintainable software and simple operation are the basic design goals for CLASS. Specific goals are listed below and the design and implementation approaches adopted to meet these goals are discussed. Easy addition of new data types  Software is general and parameterized. Parameters defining file and record structures for ingest purposes are contained in the database, so the same software can be used to process many different types of files. Likewise, the content and appearance of the web pages in the user interface are largely controlled by parameters stored in the database, so new data types and search criteria can be added easily.  Application software is object-oriented. While some software, particularly in the Ingest system, is specific for certain data types, there are many common and reusable classes CLASS-1002-CLS-PRO-Guide Page 12 CLASS Project Software Development Guide that facilitate the creation of new specialized classes through composition and inheritance. Easy addition of new functions  The application architecture is highly modular. CLASS is divided into major components, which are divided into subsystems. The more complex subsystems, such as Ingest, Recall, and Delivery, each consists of several independent processes supervised by the Activity Control System. Independence means each process performs a function based solely on the contents of the item-descriptor it receives, with no knowledge of the other processes that have handled or will handle that item-descriptor. This approach enables the implementation of new functionality in new processes with minimal impact to existing code.  The Activity Control System supports the easy modification of processing paths and the addition of new processes. Types of items to be processed (e.g., data sets, orders, line items) and processing paths (activities and triggers) are defined in database tables that can be easily modified.  The availability of utility classes facilitates the development of new processes. An Activity Control client class provides methods enabling any process to obtain itemdescriptors in priority order, update activity status, and re-queue item-descriptors. There are classes that perform common functions such as querying and updating database tables, creating log messages in standard formats, and transferring files.  Adherence to a standard design facilitates the development of new processes. All transient processes that run under the Activity Control System have the same high-level design, essentially: Initialize activity logging Open database connection DO WHILE there are items to process Get next item from queue Process item IF error Write error message to log Put item back in queue for later re-processing ELSE Let ActivityController know this activity is completed ENDIF ENDDO There are utility classes tailored to perform the common functions within this design pattern. Automatic processing and recovery  The ProcessStarter (a component of the Activity Control System) automatically starts processes when they are needed. The ProcessStarter itself is periodically restarted by cron to ensure continuous operation.  The Activity Control System automatically restarts failed processes CLASS-1002-CLS-PRO-Guide Page 13 CLASS Project   Software Development Guide The Activity Control System automatically re-queues items that may have been incompletely processed because of system failure Software is designed to recover automatically when resources are temporarily unavailable. The Activity Control System maintains a queue of item-descriptors waiting for each process. If a process cannot complete an action on an item because a resource is unavailable, e.g., a file system is filled up, that process returns the item to the queue, initiates cleanup, and periodically attempts to complete the failed action. Thus the unavailability of disk space may bring a process effectively to a halt, and this may cause other file systems to fill up and bring other processes to a halt, but item-descriptors remain queued and all processing resumes automatically once the root problem is resolved. Standard activity and error reporting  Application processes write activity and error messages in standard formats to a set of log files. A Log Monitor program periodically reads the log files and sends messages of specified types via e-mail to designated operators.  The Activity Control System monitors the activity of each process and the progress of each item through the system. It issues operator alerts (via the log file and Log Monitor mechanism) for any process that appears to be inactive or slow, or any item that appears to be stalled at some point in its processing path. Centralized monitoring and control  The Activity Control System supports centralized control of distributed processing. Process parameters (run permissions, hosts, number of instances of each process) are defined in database tables that operators can change to halt or resume processing at any point or to reconfigure the system.  A web browser operator interface enables operators to monitor processing, restart or cancel orders, modify runtime parameters in the database, and control processing through the Activity Control tables. 3.3 Coding Standards CLASS follows the coding standards defined in the Software Standards for Information Processing Division (IPD). The following programming languages are used in CLASS: C++, Java, Perl, and JavaScript. Use of any other language must be approved by the SET, and coding standards documented. CLASS-1002-CLS-PRO-Guide Page 14 CLASS Project Software Development Guide 4 Independent Testing Approach Testing for CLASS can be categorized into two areas: development testing and independent system integration and test. Development testing is discussed in Section 3.1. This section briefly describes the independent system integration and test (SI&T) approach. Further details of the SI&T activities are provided in the CLASS system Integration and Test Plan. 4.1 Levels of Testing An independent system integration and test team conducts formal integration testing of all software changes after the developer has completed development testing and the software development lead has approved the software for turnover to the test team. These tests include the following:    System build and verification in the Integration environment Promotion to the Test environment for functional and stress testing of new functionality, and regression testing Promotion to the Deployment Test environment at NCDC, for deployment testing and NCDC readiness testing The CMO controls promotion of the software to each environment as described in the Software Change Promotion Procedure. Before testing is completed, the SI&T sponsors an Operational Readiness Reviews (ORR) to validate the readiness of the software, physical and functional capabilities, and training activities. The ORR membership includes the CPMT, CCB, COT, QMO, CMO, and SI&T personnel. At the successful completion of system integration and testing, the SI&T TAL approves the release and notifies the CPMT the software is ready for promotion to operations. The NOAA CLASS Technical Lead makes the final approval of promotion to operations. The CMO then promotes the system to the Operational environment, as defined in the CM Plan. 4.2 Test Documentation Independent system testing is documented in the CLASS System Integration and Test Plan. This plan defines the approach and documentation for all levels of independent test. Separate from the SIT Plan, a regression test plan is used by the SI&T every release to ensure consistent operation of CLASS. As test cases are developed to exercise functionality, test cases may be added to the regression test plan. At the completion of integration testing, a test report is produced summarizing the release testing. This test report is included in the release folder in the CLASS document library at the conclusion of testing. 4.3 Problem Tracking Problems encountered during development testing are corrected by the developer as they are identified and do not necessarily need to be recorded. Problems encountered by the system integration and test team are recorded as Problem Reports (PRs), and the software development lead is notified of the need for correction. During the SI&T CLASS-1002-CLS-PRO-Guide Page 15 CLASS Project Software Development Guide phases, the CMO reports the status of PRs weekly to the System and Integration Test TAL. As each PR is corrected, the test team retests the function. The CLASS Technical Lead may approve promotion of the new release to operations with outstanding unresolved PRs. In that case, the PRs are converted to CCRs, since they now represent a requested change to the new operational baseline. This activity is conducted at the next CCB meeting after being discussed at the release Operational Readiness Review (ORR). Decisions from the ORR will provide the recommendation to the CLASS Technical Lead. CLASS-1002-CLS-PRO-Guide Page 16 CLASS Project Software Development Guide 5 Software Documentation Standards This section describes the standards for software design documentation and forms used to capture changes (CCR), discrepancies (PR), and activities (WR). 5.1 Software Design Documentation The following documentation outline is the standard format for CLASS design documentation. Sections not relevant to a particular design should be included and marked as N/A. Additional information should be added as necessary to convey an adequate understanding of the design. If a different format is more useful to conveying a complete picture of the changes being made and the impact to the other system components, the developer should obtain approval from her or his development lead for a revised format. After the design is implemented, much of the overview documentation presented here, including diagrams, will be incorporated into the overview sections of the software description documents in the CLASS online library. The design details should be reflected in the in-line comments and source file prologs that are extracted to produce the software reference documentation. Descriptions of database table changes will be incorporated into the database documentation. Requirements State the requirements driving this enhancement or change. Subsystem Design Overview Discuss the subsystem design or design changes at a high level. Include, as appropriate:  Subsystem processes affected - what is the function of each process and how is that functionality being altered  Database changes  New or modified user interface pages  New or modified interfaces Activity Control Paths Define new paths or path modifications for processes run under the Activity Control System. Parameter and Configuration Files Describe new files or modifications to existing files used in operations, other than executable programs. For example: site maps, style sheets, XSP files, environment files, e-mail template files. If pipeline definitions in the site map are affected, discuss and illustrate each new or modified pipeline. Storage Areas Identify new permanent or temporary storage areas required. Estimate space requirements. Indicate any special maintenance procedures (e.g., cache cleanup procedures). Log Message Give examples of new log messages to be generated. Identify log directory in which these messages will be kept. CLASS-1002-CLS-PRO-Guide Page 17 CLASS Project Software Development Guide Interprocess Communication Describe formats of new or modified interprocess messages, search results files, visualization product files. Database Tables Describe additions or changes to the structure and content of the database:  Structure - Describe new tables and modifications to existing tables. Identify column names, variable types, and contents of each column.  Content - Describe new sets of parameters to be added, e.g., to define new activity control paths or to ingest new data types. Identify all tables affected. Program Design Provide the following for each affected process in the subsystem:  Process functions.  Diagrams - Include whatever diagrams might be useful in clarifying the workings of the process, e.g., class association diagrams, state transition diagrams, activity diagrams.  Class design - Identify major attributes or methods being added or modified. Describe the input and output for each method. Describe the function of each method, using PDL for complex functions. Operational Characteristics Discuss ways in which operators may monitor and control the new or modified system. Discuss the circumstances under which an operator may be required to intervene to resolve problems. Test Plans Discuss plans for testing the changes. Identify special environments, tools, or data required for testing. Requirement Mapping Map requirements to design, i.e., provide a table in which each requirement is mapped to the above sections that describe design elements driven by that requirement. 5.2 Software Description The software description section of the online library describes the software as built. The documentation of a subsystem is generally formatted as follows:   Functions and Interfaces: High level description of functions and interfaces; context diagrams Design: Overview of subsystem design; separate subsections for overviews of major components: o Program A o Program B o Etc. Special Interfaces and Formats: Formats of external files, messages, data structures  CLASS-1002-CLS-PRO-Guide Page 18 CLASS Project     Software Development Guide Implementation: Locations of source and runtime files; build procedures; programmer notes Operation: Required environment; notes on execution and monitoring Diagrams: Class Association Diagram Reference Documents o C++ Class Hierarchy o C/C++ Classes, Structs, Unions o C/C++ Class and Struct Members o C/C++ File List o C/C++ File Members o Script List o Java Class Hierarchy o Java Class Fields and Methods o Java Package Index All the Sections except Reference Documents shown in the above outline contain overview information that must be supplied by the software developers. Some sections (e.g., Formats, Operation, Diagrams) may be omitted if not applicable. The Diagrams section of the document contains links to Tau-UML diagrams and other diagrams, preferably in PostScript format. The Reference Documents section contains only information generated by the tools doxygen, scriptdocgen, and javadoc. The locations of the online document files, tools available for generating reference documentation, and the procedures for updating the Software Description documentation are presented in the online library under Software Documentation Standards and Tools. 5.3 Configuration Change Requests At each stage of development, the supervisor for a CCR completes the relevant sections of the CCR form. The Configuration Change Request Procedure describes in detail the fields of the form and the workflow for a CCR. 5.4 Problem Reports The Problem Reports use the same tool and form as the CCRs, and are distinguished by the PR indicator. As in the CCR, the developer must identify each file that is new or changed in correcting the problem. 5.5 Work Requests Work Requests are created to document activities not affecting the CLASS system, request for document changes, or explicit system administration changes. Work Requests use the same tool and form as CCRs, and are distinguished by the WR indicator. CLASS-1002-CLS-PRO-Guide Page 19 CLASS Project Software Development Guide 6 Metrics Collection Metrics are collected throughout the development effort for both project use and to support larger scale metrics collection for the participating organizations. The metrics are collected and analyzed in order to improve planning and to identify process improvement opportunities. Refer to the Software Development Measurement Plan for all contents of release reports. 6.1 Peer Review Records Developers post completed peer review forms in the CLASS document repository for the appropriate release. A measurement spreadsheet is updated for planned release with metrics collected from these forms. 6.2 Release Folders Release artifacts are maintained in the CLASS document repository for each CLASS release, containing the following items:  Peer Reviews (reviews and waivers)  Test (test cases and reports)  Release Reports (configuration audit, ORR, promotion, and release) The Release Report contains the initial release plan, the actual release metrics, and analysis and recommendations based on the measurement data. The following items are included in the report. The Software Development Measurement Plan provides a detailed description of the release report contents.  Release Plan o The planned release scope (list of CCRs) o The release effort estimates, including the basis for estimates o The initial release schedule Release Actual (collected during and at the end of the release): o Scope (CCRs included in the delivery) o Effort o Schedule o Quality measures (e.g., record of Problem Reports identified during testing) Analysis and recommendations for future releases, including revised basis for estimates   6.3 Organizational Data Collection Each participating group in CLASS may collect and report measurement data for use within their home organization, in a form consistent with their organizational needs. The Software Development Measurement Plan outlines the CLASS measurement program. CLASS-1002-CLS-PRO-Guide Page 20 CLASS Project Software Development Guide Appendix A – Critical Computer Resources The supporting hardware and system software in the development, test, and operational environments is assessed on a periodic basis, roughly on a three-year cycle (most recently in Summer 2002). Between scheduled assessments, operations and system administration staff routinely monitor the system performance to identify changing computer resource needs. The system automatically generates operational reports indicating the level of activity in both data ingest/archive and data delivery: these reports include volume and number of datasets for each data type. Operational staff and the Operations TAL review the reports to identify usage trends suggesting current or near future demands may exceed planned capacity. Ingest/archive requirements are well defined, since they are determined by agreement with the data provider; ingest and archive activity is monitored primarily to identify system problems with the existing platform. Delivery requirements are more dynamic, and trends of higher demand than expected can result in reassessment of the computer resource capabilities outside the normal three-year cycle. The Operations TAL reports delivery statistics weekly to the CLASS Technical Lead and to the CSDPC Contract Manager, in the CLASS-MD status report, and reports any unusual activity in the monthly reports. The Operations TAL works with the CLASS Technical Lead to address any unplanned resource needs. Evaluation and selection of critical computer resources is conducted using CLASS siteappropriate acquisition management procedures. CLASS-1002-CLS-PRO-Guide Page 21 CLASS Project Software Development Guide Appendix B – Acronyms CCR CLASS CM CMO CPMT CSDPC DoD DOORS EOS GOES IPD Metop NASA NCDC NESDIS NEXRAD NGDC NOAA NPOESS NPP OSD PAL POES PR QM SAA SET TAL WBS WPI Configuration Change Request Comprehensive Large Array-data Stewardship System Configuration Management Configuration Management Office CLASS Project Management Team Central Satellite Data Processing Center Department of Defense Dynamic Object-Oriented Requirements System Earth Observing System NOAA Geostationary-orbiting Operational Environmental Satellite Information Processing Division European Meteorological Operational Satellite Program National Aeronautics and Space Administration National Climatic Data Center National Environmental Satellite, Data, and Information Service NOAA NEXt generation weather RADAR Program National Geophysical Data Center National Oceanic and Atmospheric Administration National Polar-Orbiting Operational Environmental Satellite System NPOESS Preparatory Program Office of Systems Development Project Area Lead NOAA and DoD Polar-orbiting Operational Environmental Satellites Problem Report Quality Management Satellite Active Archive Systems Engineering Team (CLASS) Technical Area Lead Work Breakdown Structure Work Product Inspection CLASS-1002-CLS-PRO-Guide Page 22