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 Description of Version Date Completed

Draft V1 Initial draft 7/22/02
1.0 Incorporated CPMT input – approved by CPMT 10/01/02
1.1 Reformatted to extract procedures to separate 07/17/03
documents
1.2 Incorporated QA review comments – approved by PM 09/02/03
1.3 New organization incorporated 9/30/03
1.4 SEPG comments incorporated 10/17/03
1.5 Incorporated SEPG review comments 9/30/04
1.5 Incorporate planning clarification 01/17/05
1.5 Approved by CPMT; changed release number upon 03/15/05
approval.
2.0 Version changed to reflect CPMT approval. 03/15/05

CLASS-1002-CLS-PRO-Guide Page i
CLASS Project Software Development Guide

Review & Approval

Software Development Guide Review History

Reviewer Version Approval Date

Reviewed
SEPG 1.5 02/09/05
CPMT 1.5 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 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 Design & System Promote to

Planning Code Integration Operations
& Test

Planning for
Future Releases

Figure 1 - Release Life Cycle

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 NESDIS OSD
Working Group Project Manager

CCB
CPMT
SET CMO

OSDPD NCDC NGDC System

Development Development Development Integration &
Team Team Teams Test Team
(Suitland, MD) (Fairmont, WV) (Boulder, CO) (Suitland, MD)

Figure 2 - CLASS Project Organization

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

CLASS-1002-CLS-PRO-Guide Page 2
CLASS Project Software Development Guide

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 Operational
Environment
(Suitland)
West Virginia Integration Suitland Test
Development Environment Environment
Environment Operational
Environment
(Asheville)
Boulder Deployment
Development Test
Environment Environment

Figure 3 - CLASS Technical Environments

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

 Software Standards for Information Processing Division (IPD), June 30, 2001
 CLASS-MD status documentation
 CLASS promotion reports

CLASS-1002-CLS-PRO-Guide Page 3
CLASS Project Software Development Guide

Additional local procedures for each participating organization may be stored in local document
repositories.

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 Software Development Guide

Release Control on CLASS:

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.

6 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.

7 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

8 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.

9 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 Code ... Code

Peer Peer Peer
Review Review Review

Unit Unit Unit

Test Test Test

Development
Developer Testing
Integration Testing

Documentation

Test Turnover
Readiness to CM
Peer Review

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.

10 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 item-
descriptors 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.

11 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.

12 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.

13 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.

14 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).

15 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.

16 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.

17 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.

18 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.

19 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.

20 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.

21 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

22 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 site-
appropriate acquisition management procedures.

CLASS-1002-CLS-PRO-Guide Page 21
CLASS Project Software Development Guide

Appendix B – Acronyms

CCR Configuration Change Request

CLASS Comprehensive Large Array-data Stewardship System
CM Configuration Management
CMO Configuration Management Office
CPMT CLASS Project Management Team
CSDPC Central Satellite Data Processing Center
DoD Department of Defense
DOORS Dynamic Object-Oriented Requirements System
EOS Earth Observing System
GOES NOAA Geostationary-orbiting Operational Environmental Satellite
IPD Information Processing Division
Metop European Meteorological Operational Satellite Program
NASA National Aeronautics and Space Administration
NCDC National Climatic Data Center
NESDIS National Environmental Satellite, Data, and Information Service
NEXRAD NOAA NEXt generation weather RADAR Program
NGDC National Geophysical Data Center
NOAA National Oceanic and Atmospheric Administration
NPOESS National Polar-Orbiting Operational Environmental Satellite System
NPP NPOESS Preparatory Program
OSD Office of Systems Development
PAL Project Area Lead
POES NOAA and DoD Polar-orbiting Operational Environmental Satellites
PR Problem Report
QM Quality Management
SAA Satellite Active Archive
SET Systems Engineering Team (CLASS)
TAL Technical Area Lead
WBS Work Breakdown Structure
WPI Work Product Inspection

CLASS-1002-CLS-PRO-Guide Page 22