1002 Software Development Guide

8/6/2019 1002 Software Development Guide

1/27

NOAANational 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


2/27

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/021.1 Reformatted to extract procedures to separate

documents07/17/03

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

approval.

03/15/05

2.0 Version changed to reflect CPMT approval. 03/15/05

CLASS-1002-CLS-PRO-Guide Page i


3/27


Review & Approval

Software Development Guide Review History

Reviewer VersionReviewed

Approval Date

SEPG 1.5 02/09/05

CPMT 1.5 03/15/05

CLASS-1002-CLS-PRO-Guide Page ii


4/27


Table of Contents

Revisions...........................................................................................................................................i

Review & Approval.........................................................................................................................ii

Table of Contents............................................................................................................................iiiTable of Figures.............................................................................................................................iv

1Introduction....................................................................................................................................1

1Introduction....................................................................................................................................11.1 General Development Approach ...........................................................................................1

1.2 Project Organization .............................................................................................................2

1.3 Development Environment .................................................................................................. 21.4 Related Documents ............................................................................................................... 3

1.5 Document Maintenance .........................................................................................................4

2Release Planning............................................................................................................................52Release Planning............................................................................................................................5

1.6 Scope Definition ...................................................................................................................61.7 Effort Estimate ......................................................................................................................7

1.8 Release Schedule .................................................................................................................. 83Software Development Process.....................................................................................................9

3Software Development Process.....................................................................................................9

1.9 Process Overview ..................................................................................................................91.10 Design Goals .....................................................................................................................12

1.11 Coding Standards ..............................................................................................................14

4Independent Testing Approach....................................................................................................154Independent Testing Approach....................................................................................................15

1.12 Levels of Testing ...............................................................................................................15

1.13 Test Documentation ..........................................................................................................151.14 Problem Tracking ..............................................................................................................15

5Software Documentation Standards.............................................................................................17

5Software Documentation Standards.............................................................................................17

1.15 Software Design Documentation ......................................................................................171.16 Software Description ........................................................................................................18

1.17 Configuration Change Requests .......................................................................................19

1.18 Problem Reports ................................................................................................................191.19 Work Requests ...................................................................................................................19

6Metrics Collection........................................................................................................................20

6Metrics Collection........................................................................................................................20

1.20 Peer Review Records .........................................................................................................201.21 Release Folders ..................................................................................................................20

1.22 Organizational Data Collection ..........................................................................................20

Appendix A Critical Computer Resources.................................................................................21Appendix A Critical Computer Resources.................................................................................21

Appendix B Acronyms...............................................................................................................22

Appendix B Acronyms...............................................................................................................22

CLASS-1002-CLS-PRO-Guide Page iii


5/27


Table of Figures

Figure 1 - Release Life Cycle..........................................................................................................2

Figure 2 - CLASS Project Organization..........................................................................................2

Figure 3 - CLASS Technical Environments....................................................................................3Figure 4 - Development Process....................................................................................................10

CLASS-1002-CLS-PRO-Guide Page iv


6/27


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 andcompatibility 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 forall 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 lessonslearned 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 ApproachThe 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 tosupport NOAA Polar-orbiting Operational Environmental Satellites.

The overall methodology used in the development of CLASS is iterative and release-based. Theiterative 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


7/27


8/27


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 eachstep are defined in later sections of this guide. Promotion of the software through this path is

described in the Software Change Promotion Procedure.

Figure 3 - CLASS Technical Environments

1.4 Related DocumentsAll 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 BaselineDocumentation>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


Suitland

Development

Environment

Integration

Environment

West Virginia

Development

Environment

BoulderDevelopment

Environment

Suitland Test

Environment

Operational

Environment(Suitland)

Operational

Environment(Asheville)

Deployment

TestEnvironment
http://opt/scribd/conversion/tmp/scratch6198/library.saa.noaa.govhttp://opt/scribd/conversion/tmp/scratch6198/library.saa.noaa.gov


9/27


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

repositories.

1.5 Document MaintenanceThis Software Development Guide (SDG) is baselined and approved by the CLASS Software

Engineering Process Group (SEPG), then the CLASS Project Management Team (CPMT). Anyproposed 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 thecourse of the project, this document will be reviewed for accuracy and updated on a yearly cycle

to reflect process improvements.



10/27


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 requirementsis 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 targetcompletion 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 theallowed 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 20days/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 schedulethrough 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 remainingCCRs 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 releaseor determine if the release schedule will need to be extended. All decisions are shared with the

CPMT membership.



11/27


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.

1.6 Scope DefinitionCLASS 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 beginassessment 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 theassignment 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 coupledthat 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



12/27


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.

1.7 Effort EstimateIn order to meet the CLASS schedule and quality commitments, accurate effort estimates are akey 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 effortestimate 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 effortestimate 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 CPMTreviews the release scope and schedule to determine if the schedule should be adjusted, the scope

revised, or additional resources applied.



13/27


1.8 Release ScheduleEach 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 ValueMethod, 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, andinter-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.



14/27


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 andcoding standards for CLASS development. Independent integration and testing activities are

addressed in Section 4.

1.9 Process OverviewFigure 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 asearly 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 fordevelopers 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 ofthe 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 approvedprocedures.



15/27


Figure 4 - Development Process


. . .

Function Level

Requirements

Analysis & Design

Design

Peer

Review

Code

Initiation

Code

Peer

Review

CodePeer

Review

Code

Peer

Review

UnitTest

UnitTest

UnitTest

Developer

Integration Testing

Documentation

Development

Testing

Turnoverto CM

TestReadiness

Peer Review


16/27


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 peerreview 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 anerror 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. Ifthe 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 ifthe 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. Anyproblems 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 completesplanning 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 developerrepeats 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.



17/27


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 plansfor 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 buildscleanly 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 thechange 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 toverify 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.

1.10 Design GoalsMaintainable software andsimple operation are the basic design goals for CLASS. Specific

goals are listed below and the design and implementation approaches adopted to meet these goalsare 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 webpages 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 Ingestsystem, is specific for certain data types, there are many common and reusable classes



18/27


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 asIngest, 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 theother 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 theaddition 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. AnActivity Control client class provides methods enabling any process to obtain item-

descriptors in priority order, update activity status, and re-queue item-descriptors. Thereare 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. Alltransient processes that run under the Activity Control System have the same high-level

design, essentially:

Initialize activity loggingOpen database connection

DO WHILE there are items to processGet next item from queueProcess item

IF error

Write error message to logPut item back in queue for later re-processing

ELSE

Let ActivityController know this activity is completedENDIF

ENDDO

There are utility classes tailored to perform the common functions within this designpattern.

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



19/27


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 temporarilyunavailable. 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-descriptorsremain 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 ofspecified types via e-mail to designated operators.

The Activity Control System monitors the activity of each process and the progress ofeach 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 appearsto 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 anypoint 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 throughthe Activity Control tables.

1.11 Coding StandardsCLASS follows the coding standards defined in the Software Standards for InformationProcessing 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.



20/27


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.

1.12 Levels of TestingAn independent system integration and test team conducts formal integration testing of allsoftware 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 andNCDC 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 OperationalReadiness 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 andtesting, 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.

1.13 Test DocumentationIndependent system testing is documented in the CLASS System Integration and Test Plan. Thisplan 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 beadded 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.

1.14 Problem TrackingProblems encountered during development testing are corrected by the developer as they areidentified 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



21/27


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



22/27


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

1.15 Software Design DocumentationThe 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. Ifa 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 documentsin 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 thatfunctionality 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 executableprograms. 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.



23/27


Interprocess Communication

Describe formats of new or modified interprocess messages, search results files, visualizationproduct files.

Database TablesDescribe 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.

1.16 Software DescriptionThe software description section of the online library describes the software as built. Thedocumentation 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



24/27


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 Hierarchyo 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 overviewinformation 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 arepresented in the online library under Software Documentation Standards and Tools.

1.17 Configuration Change RequestsAt 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.

1.18 Problem ReportsThe Problem Reports use the same tool and form as the CCRs, and are distinguished by the PRindicator. As in the CCR, the developer must identify each file that is new or changed in

correcting the problem.

1.19 Work RequestsWork 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.



25/27


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.

1.20 Peer Review RecordsDevelopers post completed peer review forms in the CLASS document repository for theappropriate release. A measurement spreadsheet is updated for planned release with metrics

collected from these forms.

1.21 Release FoldersRelease 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 thereport. 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

1.22 Organizational Data CollectionEach participating group in CLASS may collect and report measurement data for use within theirhome organization, in a form consistent with their organizational needs. The SoftwareDevelopment Measurement Plan outlines the CLASS measurement program.



26/27


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. Thesystem 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 trendssuggesting current or near future demands may exceed planned capacity.

Ingest/archive requirements are well defined, since they are determined by agreement with thedata 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 outsidethe 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.



27/27


Appendix B Acronyms

CCR Configuration Change Request

CLASS Comprehensive Large Array-data Stewardship System

CM Configuration ManagementCMO Configuration Management Office

CPMT CLASS Project Management Team

CSDPC Central Satellite Data Processing CenterDoD Department of Defense

DOORS Dynamic Object-Oriented Requirements System

EOS Earth Observing SystemGOES NOAA Geostationary-orbiting Operational Environmental Satellite

IPD Information Processing Division

Metop European Meteorological Operational Satellite ProgramNASA National Aeronautics and Space Administration

NCDC National Climatic Data CenterNESDIS National Environmental Satellite, Data, and Information Service

NEXRAD NOAA NEXt generation weather RADAR ProgramNGDC National Geophysical Data Center

NOAANational Oceanic and Atmospheric Administration

NPOESS National Polar-Orbiting Operational Environmental Satellite SystemNPP NPOESS Preparatory Program

OSD Office of Systems Development

PAL Project Area LeadPOES NOAA and DoD Polar-orbiting Operational Environmental Satellites

PR Problem Report

QM Quality ManagementSAA Satellite Active ArchiveSET Systems Engineering Team (CLASS)

TAL Technical Area Lead

WBS Work Breakdown StructureWPI Work Product Inspection

1002 Software Development Guide

Documents

Transcript of 1002 Software Development Guide