1002 Software Development Guide
1002 Software Development Guide
Revisions
CLASS-1002-CLS-PRO-Guide Page i
CLASS Project Software Development Guide
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
Table of Figures
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.
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.
Planning for
Future Releases
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
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
4 Related Documents
All CLASS baseline documents are stored in the CLASS document repository. These include
the following documents:
The following documents are available in the CLASS online library at:
http://library.class.noaa.gov/.
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
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 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 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
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 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
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
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
Design
Peer
Review
Code
Development
Developer Testing
Integration Testing
Documentation
Test Turnover
Readiness to CM
Peer Review
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.
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.
CLASS-1002-CLS-PRO-Guide Page 12
CLASS Project Software Development Guide
that facilitate the creation of new specialized classes through composition and
inheritance.
There are utility classes tailored to perform the common functions within this design
pattern.
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.
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
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:
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
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.
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
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.
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.
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
CLASS-1002-CLS-PRO-Guide Page 20
CLASS Project Software Development Guide
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
CLASS-1002-CLS-PRO-Guide Page 22