NEA Configuration Management Plan Version 1.1_Final

National Education Association

NEA INFORMATION TECHNOLOGY SERVICESSOFTWARE CONFIGURATION MANAGEMENT PLAN

(NEA SCM)VERSION NUMBER: 1.1

Version Date: 03/15/2016

1201 16th Street, NW

Washington, DC 20036Telephone: 202-833-4000

NEA Software Configuration Management Plan Version 1.1

(This page intentionally left blank)

Table of Contents

1. INTRODUCTION.................................................................................................................................1

1.1 PURPOSE........................................................................................................................................... 11.2 OBJECTIVES........................................................................................................................................ 21.3 SCOPE............................................................................................................................................... 2

2. CONFIGURATION MANAGEMENT.......................................................................................................3

2.1 ROLES AND RESPONSIBILITIES.................................................................................................................. 42.1.1 PROJECT MANAGER (PM).................................................................................................................. 62.1.2 CONFIGURATION MANAGEMENT COORDINATOR (CMC).............................................................................62.1.3 CONFIGURATION CONTROL BOARD (CCB)...............................................................................................72.1.4 CHANGE CONTROL BOARD (CCB).........................................................................................................8

3. SOFTWARE CONFIGURATION MANAGEMENT TASKS........................................................................9

3.1 SOFTWARE CONFIGURATION MANAGEMENT RESOURCES.............................................................................103.2 APPROACH....................................................................................................................................... 113.3 ORGANIZATION.................................................................................................................................. 123.4. CONTROL........................................................................................................................................ 123.5 IDENTIFICATION................................................................................................................................. 123.6 PLANNING........................................................................................................................................ 133.7 STATUS ACCOUNTING.......................................................................................................................... 133.8 VERIFICATION AND AUDIT..................................................................................................................... 133.9 TRAINING......................................................................................................................................... 13

4.0 ASSUMPTIONS / CONSTRAINTS / RISKS............................................................................................13

4.1 ASSUMPTIONS................................................................................................................................... 134.2 CONSTRAINTS.................................................................................................................................... 134.3. RISKS............................................................................................................................................. 14

5.0 SOFTWARE CONFIGURATION MANAGEMENT APPROACH................................................................14

5.1 METHODS & TOOLS........................................................................................................................... 145.2 ROLES & RESPONSIBILITIES................................................................................................................... 155.3 ENVIRONMENT.................................................................................................................................. 15

6.0 SOFTWARE CONFIGURATION MANAGEMENT ADMINISTRATION.....................................................16

6.1 CONFIGURATION IDENTIFICATION...........................................................................................................166.2 NAMING STANDARD........................................................................................................................... 176.3 BASELINES........................................................................................................................................ 186.4 STORAGE & RETENTION....................................................................................................................... 196.5 IMPACT ANALYSIS............................................................................................................................... 196.6 TRACKING & CONTROLLING CHANGES TO CI BASELINE................................................................................206.7 CONFIGURATION INTEGRITY..................................................................................................................226.8 CONFIGURATION STATUS ACCOUNTING....................................................................................................236.9 CONFIGURATION AUDITS...................................................................................................................... 23

7. DESCRIPTION OF RELEASE TYPES........................................................................................................25

8. CONFIGURATION CONTROL................................................................................................................26

i

8.1 CONFIGURATION ACCOUNTING.............................................................................................................. 268.2 PACKAGED RELEASES.......................................................................................................................... 268.3 PREPARING FOR TEST.......................................................................................................................... 278.4 CHECK-IN/CHECK-OUT PROCEDURES.......................................................................................................27

9. RELEASE PROCESS...............................................................................................................................27

10. ROLES...............................................................................................................................................27

APPENDIX A: RECORD OF CHANGES.......................................................................................................30

APPENDIX B: ACRONYMS.......................................................................................................................31

APPENDIX C: GLOSSARY.........................................................................................................................33

APPENDIX D: REFERENCED DOCUMENTS................................................................................................38

APPENDIX E: APPROVALS.......................................................................................................................40

Table of Figures

Figure 1 - SCM Flow Chart Process...........................................................................................................3Figure 2 - Impact Analysis Functionality Process....................................................................................20Figure 3 - CI for Hardware/Software Systems.........................................................................................22Figure 4 - Configuration Audit Process Flow...........................................................................................24

Table of Tables

Table 1 - Configuration Products............................................................................................................12Table 2 - Software Configuration Management Process........................................................................14Table 3 - Roles and Responsibilities.......................................................................................................15Table 4 - Document Revision History.....................................................................................................17Table 5 - Release Numbering.................................................................................................................18Table 6 - NEA Configuration Items.........................................................................................................24Table 7 - Record of Changes...................................................................................................................30Table 8 - Acronyms................................................................................................................................31Table 9 - Glossary...................................................................................................................................33Table 10 - Referenced Documents.........................................................................................................38

ii

1. Introduction

The National Education Association (NEA) Software Configuration Management Plan (SCMP) describes processes for documenting the software configuration management requirement approach for the NEA system. This SCMP specifically addresses configuration management for software. Configuration management for hardware, change management, database and development, third parties, and other components are addressed within their own individual plans. The SCMP describes the NEA SCM best practices for SCM. This document includes sections on:

Process description, which includes scope and objectives;

Process policies;

Process flows and activities;

Process roles and responsibilities; and

Process metrics.

1.1 Purpose

The purpose of Software Configuration Management (SCM), in general, is to establish and maintain the integrity of work products using:

Configuration Identification Configuration Control Configuration Status Accounting Configuration Audit

A Configuration Item (CI) is an entity designated for configuration management, which may consist of multiple related work products that form a baseline. This logical grouping provides ease of identification and controlled access. The selection of work products for configuration management should be based on criteria established during planning. This SCMP contains detailed information about CIs.

Configuration Identification

The purpose of Configuration Identification is to define the functional and physical characteristics of a CI in sufficient detail so that it may be developed, tested, evaluated, produced, competitively procured, accepted, operated, maintained, and supported. Configuration identification is established by baselines plus approved changes. For purposes of this SCMP, Configuration Identification includes the selection, creation, and specification of the following:

Products that are delivered to the client

1

Software Configuration Management Plan

SEM documents requiring Structured Walkthroughs (SWT)

Configuration Control

The process of evaluating, approving or disapproving, and managing changes to controlled items. This includes tracking the configuration of each of the CIs, approving a new configuration if necessary, and updating the baseline.

Configuration Status Accounting

The process of creating and organizing the information necessary for the performance of configuration management. An element of configuration management consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes.

Configuration Audit

Audits are conducted to verify that a CI, or a collection of CIs that make up a baseline, conforms to a specified standard or requirement. This includes functional and physical configuration audits.

1.2 Objectives

This SCMP defines the configuration management policies and procedures required for this project. This plan has been developed early in the lifecycle to ensure the control of changes as soon as the project requirements are approved. This plan addresses activities that are platform independent, such as identifying the items that will be placed under configuration management. As the project progresses through the lifecycle stages, the plan is expanded to reflect the platform specific activities.

Changes in this system affecting other SCM plans are identified and explained under sections “Software Configuration Management Resources” and “Software Configuration Tasks” of this plan.

1.3 Scope

The scope of this plan extends to configuration items (CI) developed or implemented for the system’s software development life cycle (SDLC). The NEA SCMP addresses the SCM activities at the program level. The SCMP is a dynamic document that is used by the NEA Team and housed in the share drive and SharePoint that are used as repositories for storing and providing access to SCMP documents.

Intended to be used by the project manager, project team, project sponsor, and any senior leaders, the SCMP provides processes, procedures, and environmental structures that will

2


Denise, 03/18/16,

Which share drive?

be used to ensure control over application software and database related components as they progress from the software development stage through integrated system testing, user acceptance testing, quality assurance (QA), training, and production environment. The SCMP is required to ensure the integrity of the software, validity of testing, and to reduce the introduction of bugs into the production environment.

2. Configuration Management

The following sections describe the components of the Software Configuration Management organization which are necessary to support the management of NEA. Software Configuration Management interfaces directly with systems development, testing, change management, QA and release management to incorporate new and updated product deliverables. The SCM control should be passed from the project or supplier to the service provider at the scheduled time and with accurate configuration records.

Figure 1 - SCM Flow Chart Process

2.1 Roles and Responsibilities

Only the responsibilities related to SCM are listed here.

3


The following documents, procedures, and roles comprise the Software Configuration Management process:

Configuration Control Plan. The configuration control plan defines the policies and methods used to establish and control the configuration items identified in section four by the formally constituted enterprise manager;

Software Configuration Management Status Accounting. Software Configuration Management status accounting describes the plans for status accounting, which track and documents changes for historical reference;

NEA Software Development Team. The NEA Software Development Team is responsible for ensuring the baseline is used when configuring equipment and baselines are in accordance with all NEA policies and directives;

Software Configuration Management Plan. The SCM plan outlines and describes the project’s Software Configuration Management practices, which are based on the generally accepted industry standards in manufacturing software development; and

The following list of responsibilities comprises the Software Configuration Management process:

Arbitrating in any dispute over the allocation of resources and/or responsibilities;

Defining and improving the audit process;

Defining the critical success factors (CSFs) and key performance indicators (KPIs) for the process;

Directing and scheduling the training of new CI owners and CI coordinators;

Ensuring appropriate security and access levels to the SCM;

Ensuring regular housekeeping of the SCM system data;

Directing, prioritizing, and scheduling audits; and ensuring that any corrective action identified in the process and/or database audits are carried out;

Ensuring that all relevant staff have the required technical and business understanding, knowledge and training in the process, and are aware of their role in the process;

Ensuring that staff comply with the process and data standards;

Ensuring the configuration process is Fit-for-Purpose that is responsible for the process design;

4


Evaluating performance metrics against the defined critical success factors and institutes actions to correct shortcomings or further streamline the process as necessary;

Executing the process controls;

Identifying opportunities and submitting proposals for improvement with respect to tools, staff, training, processes, procedures, and work instructions;

Interfacing with other processes and/or business functions to ensure they are able to leverage the benefits provided by the Software Configuration Management process;

Managing any new requirements or changes to the process;

Managing, monitoring, reviewing and updating all procedural documentation and work instructions;

Managing the evaluation of SCM and recommending those that best meet the organization’s requirements;

Monitoring and reviewing the execution of periodic audits;

Monitoring and reviewing the execution of the SCM process at a high-level, ensuring it remains consistent with the organization’s current culture and information technology (IT) service management strategy, and coordinating with all other IT processes;

Planning and managing the SCM population, including discovery and other data import methods;

Producing reports and management information, including impact analysis reports, and configuration status reports;

Promoting the service management vision to top-level/senior management;

Providing the description, mission statement, roadmap, strategy, and process objectives and metrics to measure success and obtain formal approval for the Software Configuration Management process and its associated procedures; and

Sponsoring the communication campaign to promote awareness and acceptance of the SCM.

2.1.1 Project Manager (PM) Establish the overall project schedule for SCM activities with Configuration

Management Manager (CMM)

5


Make sure team members are knowledgeable of SCM concepts and techniques and that they are applied to project activities

Ensure compliance with the SCM standards and procedures set by the CMM, the Configuration Control Board (CCB), and any other affected groups as outlined in this plan.

2.1.2 Configuration Management Coordinator (CMC)

The project CMC will prepare the SCM Plan with assistance from the Project Manager. The CMM is responsible for creating and/or updating the SCM Plan, as well as communicating the contents of the plan to the project team.

Make sure team members are knowledgeable of SCM concepts and techniques and that they are applied to project activities.

Ensure compliance with the SCM standards and procedures set by the CMC, the Configuration Control Board (CCB), and any other affected groups as outlined in this plan.

Responsibilities

SCM Planning

Identify the Configuration Items (CIs) to be managed under the SCM processes Create, manage and maintain the SCM Plan, standards, and procedures Communicate any changes to the SCM Plan, standards, and procedures to all

stakeholders Make sure that all project team members involved in the SCM process receive

training on their roles Make updates to the SCM Plan, as appropriate Make sure that any updates to the SCM Plan are communicated to the appropriate

project team members Form and lead a SCM Team Approve changes to the SCM Plan

Implementing Changes

Participate as a member of the Configuration Control Board (CCB) Create SCM products (baselines, application environments), as authorized by the

CCB Process and track software change requests Function as the point of contact with Infrastructure Services to analyze proposed

changes and to insure interoperability between hardware and software components

6


Tracking, Reporting and Audits

Make sure that configuration item change requests and problem reports for all CIs are initiated, recorded, reviewed, approved, and tracked according to the SCM Plan

Ensure all Functional and Physical Configuration Audits are performed Respond to requests for status regarding SCM activities from managers and

auditors

2.1.3 Configuration Control Board (CCB)

Responsibilities

Monitor changes and updates to project requirements Authorize the establishment of baselines and the identification of CIs Ensure that all approved changes and updates to CIs are placed under

configuration control Use the SCM Plan as its primary decision-making resource Support and provide input to Local Change Board (LCB) and Enterprise Change

Board (ECB) functions related to the DTMB Service Management Center Request for Change (RFC) process

Review and authorize changes to the baselines Attend regularly scheduled meetings Review and discuss new change requests Prioritize change requests Authorize research on change requests Approve the commencement of work on change requests (make active) Review the status of active change requests Create and communicate minutes from the CCB to affected groups

Roles

Members Roles

System Owner Representative from customer agency with decision making authority

Project Manager (PM) Project Manager for the application system

Application Development Functional Manager(s) Development Manager(s)

Configuration Management Manager (CMM) Service Provider

7


2.1.4 Change Control Board (CCB)

Responsibilities

Ensure changes do not adversely affect other systems Authorize changes to the systems

Roles

The ECB is primarily staffed with DTMB Infrastructure representatives. Attendance at ECB meetings by the local staff will vary depending on the scope of the change. Typically only one or two of the following will attend.

Members RolesDTMB Agency Service (AS) Client Service Director (CSD) Stakeholder

Application Development Functional Manager(s) Development Manager(s)Client Support Specialist Client SupportInfrastructure Specialist Agency Services SupportConfiguration Management Manager (CMM) Service ProviderSubject Matter Expert(s) (SME) Subject Matter Expert(s)

3. Software Configuration Management Tasks

This section consists of the following:

Identification of Configuration Items Configuration Items Baseline Identification Repository Identification Configuration Item Identifier

Software Configuration Management Tasks

This section consists of the following:

8


Identification of Configuration Items Configuration Items Baseline Identification Repository Identification Configuration Item Identifier

Identification Configuration Items

The terms Configuration Identification and Configuration Item are defined in Section 1.1 of this document.

In this SCM Plan, work products are considered for configuration management based on the following criteria. A work product is any tangible item that results from a project function, activity or task.

May be used by one or more work groups Are expected to change over time either because of errors or change of

requirements Are dependent on each other in that a change in one mandates a change in

another/others Are critical to the project

Items in the following categories are selected to be placed under configuration management:

Project Management documentation, including Project Plan and Project Charter SEM documentation, including all deliverables, Structured Walkthroughs (SWT),

Stage Exit Position Response form Models Interfaces Process descriptions Product/Application data such as lookup tables, system files Source code and executable code Test scripts Test data Metrics, status reports, quality review reports, etc. Support tools, including compilers, editors, testing tools Touch Point documentation including EA solution documents, Infrastructure

Services Request (DTMB-0184), and Security Plan and Assessment (DTMB-0170)

Configuration Items

The following table contains CIs that are included in this SCM Plan.

9


Configuration Items Description/SUITE Form

Responsible for placing item under

control

When item is put under control

Baseline Identification

In this SCM Plan, a software baseline is created by the identification and labeling of CIs at a specific point in time. A baseline represents the current approved configuration.

3.1 Software Configuration Management Resources

The NEA operates in a rapid pace within a web-based environment. Using configuration resources, the developer continually adds updates to the SDLC.

Software Configuration Management tools that are used for NEA are as follows:

ACAP.Net. ACAP.Net is the latest iteration of NEA’s Association Compensation Analysis Program. ACAP is part of NEA’s strategy to ensure a quality workforce in the public schools. It takes adequate compensation to attract, retain, and motivate the best people to serve America’s children. ACAP helps NEA and its affiliates work with members to reach those goals;

Beanstalk. Request a code review, assign reviews, and get to work. The review process is designed to start the discussion early and integrates directly with your branch, resulting in more feedback from your team. Code Review allows for two types of feedback, Issues and Discussions. Comments that require a specific action are separated into issues so you know exactly what’s in the way of getting your feature approved.

DuShane Legal Management System (DLMS). The DLMS software is used by developers as a reporting tool. This software is designed to provide members and local affiliates with the appropriate level of assistance in employment-related legal proceedings;

JIRA. JIRA is the name of a software program that is used by software teams to track and resolve issues, such as bugs and defects. It is also used as a management tracking, change management, and service request tool;

Microsoft SharePoint. Microsoft SharePoint is a browser-based collaboration and document management platform. This content management system allows NEA to set up a centralized, password protected space for document sharing that provides indexing and version-control;

10


National Compensation Analysis System (NCA). NCA is a companion application for ACAP.Net. NCA is the place where data from ACAP.Net is rolled up into salary rankings, benchmarks, and other kind of aggregate information about compensation for public school employees;

PAC Accounts Receivable System (PARS). PARS automates invoicing and performs fast, efficient, and automated accounts receivable management;

PowerBuild. PowerBuild is an object oriented development environment;

Software Change Request Repository (SCR). The software change request repository (SCR) is used to store Microsoft SharePoint and soon Visual Studio Team services; and

Visual Studio Team Services. Visual Studio Team Services provides a set of cloud-powered collaboration tools that work with an existing IDE or editor, so that a team can work effectively on software projects of all shapes and sizes.

3.2 Approach

This Software Configuration Management Plan (SCMP) is a process to establish the NEA Software Configuration Management requirement approach for the system. The scope of this plan extends to CIs developed or implemented for the system’s SDLC. The SCMP is a dynamic document that is periodically updated, as needed.

3.3 Organization

The NEA and the SCM Team needs to ensure that CIs managed by other organizations are controlled appropriately and do not affect program deliverables. It is expected that changes to these items are coordinated with the users by the organization responsible for its maintenance. The following table is managed by other organizations and identifies the work products and/or tools that are managed by other teams:

Work Product/Tool Organization Responsible for Updates

Compilers NEA

11


Work Product/Tool Organization Responsible for Updates

COTS Products NEA

Government Furnished Software NEA

Monitoring Tools NEA

Network NEA

Operating Systems NEA

Servers NEA

Support Tools NEA

Utilities NEA

Table 1 - Configuration Products

The basic activities of Software Configuration Management are as follows:

3.4. ControlFrom receipt to disposal, the control process involves ensuring that only authorized and identifiable CIs are accepted and recorded. It ensures that no CI is added, modified, replaced or removed without the appropriate control documentation, e.g. an approved change request (CR), and an updated specification.

3.5 IdentificationThe identification process involves selecting and identifying the configuration structures for all the infrastructure’s CIs, including their ‘owner’ and their interrelationships and configuration documentation. It includes allocating identifiers and version numbers for CIs, labelling each item, and entering the Software Configuration Management database (SCMDB).

3.6 PlanningThe Software Configuration Management process involves planning and defining the purpose, scope, objectives, policies and procedures, and the organizational and technical context for configuration management.

3.7 Status AccountingThe status accounting process involves the reporting of all current and historical data concerned with each CI throughout its life cycle. This enables changes to CIs and their records to be traceable; the same traceability to CIs and their records to be traceable; that all CIs will follow the same traceability from the beginning to the end of the SDLC process; and that the CIs track the status of CIs as it changes from one state to another.

12


3.8 Verification and AuditThe verification and audit process consists of a series of reviews and audits that verify the physical existence of CIs and check that they are correctly recorded in the Software Configuration Management system.

3.9 Training

The SCM Plan provides for training on new and existing configuration tools to NEA Staff as needed.

4.0 Assumptions / Constraints / Risks

4.1 AssumptionsThe NEA project assumes that it is possible to define a decision mechanism whenever more than one solution is available. Due to the minimal allocation of resources any potential disagreement can facilitate a lengthy deployment of the project itself.

The NEA project is also based on the goodwill of the user community to help in the definition and in their contribution to the implementation of the infrastructure.

4.2 Constraints Business interruptions or reorganizations in the midst of the project; Lack of skilled resources; Poor communications; Stakeholders have unrealistic expectations of project outcomes; Stakeholders’ unrealistic expectations of project outcomes; Stakeholders’ unrealistic expectations of the project schedule; and Uncertain economic times or business conditions.

4.3. Risks

Cause: Our project requires the installation of a new server and we decided to have an external vendor install the software; many subsequent project tasks are dependent upon the installation of the new server.

Event. There is a very low chance that the vendor will be late installing the new operating system; previous experience with this vendor has shown very good performance in completing their work as contracted. If the vendor is late by two weeks,

Impact. Then our delivery of new features will be four weeks later than committed and project costs will increase by about 10%.

13


5.0 Software Configuration Management Approach

5.1 Methods & Tools

Software Configuration Management

The program team needs to ensure that configuration items that are managed by other organizations are controlled appropriately to not affect their program deliverables. It is expected that changes to these items are coordinated with the users by the organization responsible for its maintenance. Table 2 Software Configuration Management Process Managed by Other Organizations identifies the work products and/or tools that are managed by other teams

Process Tools & TechniquesN/A JIRAN/A Visual Studio Team ServiceNA SharePoint

Table 2 - Software Configuration Management Process

5.2 Roles & Responsibilities

The roles and responsibilities for Software Configuration Management are defined in the NEA Project Management Plan.Name Role ResponsibilityKenneth Stephens Software Configuration

Management & Release Coordinator

N/A

Table 3 - Roles and Responsibilities

5.3 Environment

Development (Development Testing - DVL)

14


This environment will be used for the initial software construction, unit and initial system testing, and software modifications arising from the change management process. All application software changes will originate in this environment.

Test (Integrated System Testing - TST)This environment will be used for detailed system testing and integrated system testing as defined in the Client Server Testing Strategy document. The test data and database will contain data that has been generated specifically to support structured testing.

It is assumed that legacy data conversion, development, execution, and testing, will take place within the development and testing environments. The objective of the conversion testing is to make sure the conversion software is functioning as designed, and to validate the converted data.

QA (User Acceptance Testing - QA)This environment will be used for user acceptance testing and training for the business users. This environment will also facilitate performance and volume testing. The database and other test data for this environment will contain data that reasonably simulates the actual or anticipated production data and data created from legacy conversion efforts.

Training (Training)This environment will be used to stage all of the software components that are approved and ready for production migration. The Production Management Team will implement the software to live production from this environment.

Production (PRD)This environment will be used solely for live execution with production data to support the business information processing needs. This environment will include the necessary file servers on the LAN and WAN to support the distribution of software and databases.

6.0 Software Configuration Management Administration

6.1 Configuration Identification

The purpose of the CI activity area is to determine the metadata for a CI—to uniquely identify it, and specify its relations to the outside world and other CIs. Identification is one of the corner stones of SCM, as it is impossible to control something whose identity one does not know.

This section will identify all types of configuration items that are described as formal and managed/controlled configuration.

Formal control is a level of Software Configuration Management applied to work products that may only be changed with a documented CR that is approved by the appropriate NEA Program authority. The NEA Program Authority is responsible for evaluating and approving or disapproving proposed changes to formal configuration items and for ensuring the implementation of approved changes.

15


Stevens, Kenneth, 03/15/16,

Need to verify if NEA still using LAN and WAN or MS Server and UNIX or LINUX

Managed and controlled configuration is a level of Software Configuration Management that is applied to work products that require less rigor than formally controlled items. However, these work products are important to program success and must be maintained appropriately. Changes to these work products must be controlled, and steps should be taken to ensure the correct version of the work product is used. These work products would not be included in baseline verifications. Managed and controlled CIs may utilize a CR or change specification to track the change being made, but the CI owner or designee may approve the CR.

A CI naming convention is needed when completing the CSCI Identification matrix, as part of the version description document (VDD). When using the SCM Tool, the CSCI will be determined automatically by the SCM Tool when entering into the SCM Repository via the SCM Tool.

In the NEA Program, when entering the file name for code files into the SCM tool, do not include a date, version or special characters (an underline is allowed) in the file name. The creation date assigned by the operating system will be originally recorded by the SCM Tool as one part of the unique ID assigned by the SCM Tool.

6.2 Naming Standard

This section provides the naming standards for all types of CIs developed or maintained by NEA. All documentation and software components will follow NEA established standards, including the NEA.

Documentation

Documentation files (i.e. processes, procedures, version description documents) will have an internal document history revision required as part of each document where the author of the changes will track the updates that have been applied. This internal document revision number is internal to the document (found in the revision history page) and should not be confused with the document version within Microsoft SharePoint. The initial version of a document will be version 1.0 and each subsequent version with minor changes will be numbered in .1 increments. Major changes will increase the version number by a single digit (i.e. from 1.3 to 2.0).

Each document must have this internal revision history at the beginning of each document:

16


CR# (optional)

Document Version #

Approval Date Modified By Section, Page(s), and

Text Revised

1.0 Initial Submission

Table 4 - Document Revision History

ReleasesAs work products are bundled together for a release, a version number will be assigned to the release. Release version numbers will follow a standard naming convention.For release identification, the release itself and each of the CIs contained within the scope of the release are identified with a unique naming and numbering scheme. The Release identification will be assigned to labels that will be attached to all CIs that it represents. The release numbering scheme will have the format XX.YY.ZZ.BBa, which is described as follows:

XX = version numberYY = point release numberZZ = change numberBB = Packaged Release numbera = emergency

An explanation of the numbering format is provided in Table 3-4 Release Numbering.

Name Definition Sample ValueVersion Release The first placement is the version number. 01.00.00

Point Release The second placement is the point release number. 01.01.00

Change Release The third placement is the change release number. 01.01.01

Packaged Release

The internal tracking sequential number to track what files are being implemented with a particular release Packaged Release

01.01.01.01 (.xx – Packaged Release number for internal use only.)

Emergency Release

A letter designation indicating emergency change. The letter designation a-z (lowercase).

01.01.01.01a

Table 5 - Release Numbering

17


6.3 Baselines

A baseline may be used as a starting point, snapshot or safe recovery point. The baselines are promoted individually within the NEA approved SCM Tools. Baselines are created when the appropriate work products have been reviewed, approved, and promoted to the baseline library within the SCM Repository. Baselines may be updated only through the use of approved change control procedures.

After a release has been implemented into production and verified, a merge must be performed with the main trunk and the changes implemented into production. Planned baselines are indicated in the table below. Each work product will have its specific version.

NEA tools will store the document and software baselines.

Allocated - The performance of each CI in the allocated baseline is described in its item performance specification.

Development - The development baseline’s major components are the generation of the computer programs (code) and the database. Other components are the training documentation, user’s, operations, and maintenance documentation.

Functional - The functional baseline, sometimes called the requirements baseline, is the main product of the Define System Phase and is managed in accordance with the Functional Requirements Document and Data Requirements Document. Include a subsection for software and documentation, including design documentation, if applicable.

Product - The product baseline is established during the Evaluate System Phase. The product baseline’s major component is the end system product as built by the developers. This includes the following:

o The product baseline is established after successful completion of the functional configuration audit (FCA), physical configuration audit (PCA) and associated system products and audit results presented at the Evaluate System review. This baseline incorporates all changes needed to resolve problems detected during system acceptance and release testing and any discrepancies between the system, its requirements, and design documentation

Test - The user acceptance evaluation criteria component of this baseline is defined in the Verification, Validation and Test (VV&T) Plan.

6.4 Storage & Retention

The NEA SharePoint administrator will work with the NEA Team and NEA personnel to define and implement the library structure for the NEA SharePoint site. The NEA source code will be stored in SCMS repositories such as JIRA, Visual Studio Team Service, and

18


SVN. All SCMS repositories have the capability to provide a storage source code and maintain the code history.

6.5 Impact Analysis

The main principle is “control.” The evolution of software should not be inhibited, however, there is a need for a mechanism that manages and approves proposed changes. Chaos becomes a possible outcome if QA engineers were expected to test software systems where developers changed the software without adjusting the requirements. Software development is a complex task, therefore, applying tools and processes (SSCM) helps streamline the effort to ensure repeatability, productivity, and quality improvements.

The reasons for changing software can usually be narrowed to one of a few key reasons:

1. Developer Innovation – This is an often-overlooked aspect of software development projects. Software is changed in subtle ways, often for the better, and without an approved CR.

2. Enhancement– A new feature or a change to an existing feature is requested (hopefully leading to a product improvement); and

3. Software Defect – Bugs do exist and can be an ongoing challenge.

Figure 2 - Impact Analysis Functionality Process

6.6 Tracking & Controlling Changes to CI BaselineThe objective of establishing a baseline is to define a basis for further SDLC process activity and provide references to, control of, and traceability among CIs and requirements. It serves as the common reference that all system development activity is built on. It also dictates to the Development Team the changes that are to be implemented. The purposes for baselines are as follows:

Baselines shall be established for CIs. Developmental baselines will be established to aid in controlling SDLC processes; and

19


Production baselines shall be established upon implementation of the first phase of the Interim NEA system. Further changes to the production baseline require review and approval by the NEA Enterprise Manager.

Baselines are established in a system development effort to define a formal departure point for controlling future changes that affect performance or design. A baseline, once defined and approved, is placed under SCM, after which any changes in the baseline should be formally documented and approved. Each packaged release should have a unique release label. Product baselines should be reviewed and approved with an approval memo and attachments for the description of any discrepancies that are part of the release.

The following items should be included in each center’s baseline. All NEA related requirement and design documents, at minimum, should contain:

All messages the center will publish and subscribe to;

All NEA related data and configuration files;

All NEA related test plans and test plan results;

All non-proprietary development code required to packaged release the NEA components;

Description of actions taken upon receipt of “request” messages;

Field by field descriptions of how the published messages will be populated; and

Field by field descriptions of how received messages will be used by the center.

The objectives of these Software Configuration Management procedures are to:

Enhance the quality of production software;

Improve responsiveness to requested changes;

Increase the efficiency of development and testing processes; and

Maintain a high level of end user satisfaction and confidence in NEA’s application; software.

These objectives will be achieved by promoting a structured development and testing environment, unauthorized moves into and within these environments, enforces enforcing a disciplined and organized approach to software migrations, and establishing the necessary environment and procedures to support multiple, concurrent application releases.

20


Each environment (DVL, TST, QA, STG, Training, and PRD) will consist of a set of standard directories to organize the components of the application and facilitate software migration between environments. The developer has the authority to review, write, and execute privileges for users to gain access to system environments from DEV to production. This is done to ensure the integrity of individual software components within each environment. Based on application and function, each developer, tester, end user, and system administrator will be assigned to a particular group. In turn, specific groups will have authorized access based on their roles and functions.

6.7 Configuration IntegrityEnsuring the integrity of hardware and software configurations requires the establishment and maintenance of an accurate and complete configuration repository. This process includes collecting initial configuration information, establishing baselines, verifying and auditing configuration information, and updating the configuration repository, as needed. Effective Software Configuration Management facilitates greater system availability, minimizes production issues, and resolves issues more quickly.

Figure 3 - CI for Hardware/Software Systems

Configuration Control involves establishing and maintaining an accurate and complete repository of all configuration attributes, source codes, and CIs for all NEA projects. The configuration control procedure describes how to manage changes to CIs throughout the SDLC of the program. The NEA standard configuration item control procedure will be conducted as follows:

21


Establishing a central repository of all configuration items;

Identifying configuration items and maintaining them; and

Reviewing the integrity of configuration data.

They are measured by the:

Number of business compliance issues caused by improper configuration of assets;

Number of deviations identified between the configuration repository and actual asset configurations; and

Percent of licenses purchased and not accounted for in the repository.

6.8 Configuration Status AccountingSoftware Configuration Management activities involve the recording and reporting of information needed to effectively manage established baselines and those being established during the development process. This process helps to maintain configuration integrity during change control and development periods by ensuring the status accounting records, documents, and executable system files are consistent. The project configuration manager produces a report that reflects the proposed, currently approved, and validated versions of the work products and the software Software Configuration Management baselines.

The four principle sources for software configuration status reports are:

Audits;

Change requests;

Software Packaged Releases; and

Version descriptions.

6.9 Configuration Audits

The configuration and audit is a management process that confirms the integrity of a systems product prior to delivery. There are two types of configuration audits:

Functional Audit. The objective of the functional audit is to provide an independent evaluation of a software product and to verify that its configuration items' actual functionality and performance is consistent with the relevant

22


requirement specification. This audit is held prior to software delivery to verify that all requirements specified in the software requirements specification have been met.

Physical Audit. The objective of the physical audit is to provide an independent evaluation of a software product's configuration items to confirm that all components in the as-built version map to their specifications. Specifically, this audit is held to verify that software and its documentation are internally consistent.

The following table contains the configuration items required for the NEA project:

Baseline Configuration Item Control When BaselinedFunctional Requirements Document Formal Requirements Sign-off

Project Work Plan Informal Requirements Sign-offAllocated Design Document Informal


Formal NEA Director Sign-off

Table 6 - NEA Configuration Items

23


Figure 4 - Configuration Audit Process Flow

An environment is the set of resources used to perform the tasks and functions associated with each level of the SDLC. In other words, each level in the migration path, from initial development through production implementation, is considered an environment. The environment resources are uniquely identified through naming standards, and are access controlled. An environment consists of root directories that are on UNIX and LAN servers, at least one database, and one or more Visual Studio Team services developer, tester, and/or end-user workstation configurations.

7. Description of Release TypesApplication software releases will fall into one of the following four categories:

Package Release (Major Release). An package release would contain a significant collection of major functional enhancements. The development and testing for this type of release will take place in a path created specifically for the enhancement release.

Critical (Emergency or Patch Release). An critical release would contain from one to several critical fixes and/or high priority minor enhancements. There are three types of interim releases and they include a production interim release; a maintenance interim release; or an enhancement interim release. The development and testing for this type of

24


release will take place in either the path designated for production fixes, maintenance releases, or for an enhancement release that depends upon the interim release type.

Internal (Non-External Release). An internal release is used for team testing and internal QA test activities, also known as iterative type system testing. For each iteration of internal testing, the fourth digit of the release number is incremented to indicate that a change has occurred. The development and testing for this type of release will take place in the development, testing, and QA areas within the version of the system.

Release Name SampleRelease Number Example: 1.0.3.4Where 1 is the major release 0 represents the minor release (maintenance release) 3 represents the 3rd interim release 4 represents the fourth internal system test iteration

Normally, the end-user will not see that the version number has a fourth character, as it is only used internally by the Systems Development Team.

This document will focus primarily on enhancement releases and with the understanding that interim and maintenance releases will follow a similar but not identical process. The major difference will be in the scope and breadth of the enhancement, as it relates to the path where the development and testing will take place, and the level of testing required to ensure accuracy, validity, and effectiveness, etc. In other words, the interim and maintenance releases may not require a full test or their own development path, so a subset of these procedures will apply to those types of releases.

As far as the end-user can see, the application software releases will be numbered in the format, x.y.z, where x is the initial release or the latest enhancement release, y is the latest maintenance release within x, and z is the latest interim release within y. For example, an initial release would be 1.0.0. A subsequent interim release would be 1.0.1. A maintenance release following 1.0.1 would be 1.1.0. The last digit in the release version is usually hidden from the user, which indicates the internal release number as mentioned earlier.

8. Configuration ControlThe purpose of configuration identification (CI) is to define the functional and physical characteristics of a CI in sufficient detail so that it may be developed, tested, evaluated, produced, competitively procured, accepted, operated, maintained, and supported. CIs are established by baselines plus approved changes. For purposes of this SCM Plan, CIs include the selection, creation, and specification of the following:

A clear audit trail of all proposed, approved or implemented changes exists; Configuration control tools and techniques; No change is made to the product baselines without authorization; The latest approved version of the product and its components are used at all

times.25


8.1 Configuration AccountingSoftware Configuration Management activities involve the recording and reporting of information needed to effectively manage established baselines and those being established during the development process. This process helps to maintain configuration integrity during change control and development periods by ensuring the status accounting records, documents, and executable system files are consistent. The project configuration manager produces a report that reflects the proposed, currently approved, and validated versions of the work products and the software Software Configuration Management baselines.

The four principle sources for software configuration status reports are:

Audits. Change requests; Software Packaged Releases; and Version descriptions.

8.2 Packaged Releases

The development team lead, or an assigned, “application architect” for the Development Team will be responsible for assembling all the components necessary to perform the packaged release for the development environment. The architect will play a key role in coordinating the Subversion (SVN), Visual (VS) Team Services, PowerBuilder PFC, NEA base class, and PowerBuilder version, as they relate to the application that is currently under development. This includes determining which versions will be used for the production packaged release, and freezing all subsequent changes to these components, as they relate to and affect the application under development.

8.3 Preparing for Test

The development team lead will be responsible for providing all components, documentation, and knowledge necessary to Packaged Release the application for subsequent promotion to the test environment. Since the software will eventually progress to production through the test environments, all known components that will be required for production implementation should be provided by the Development Team prior to the commencement of the first test cycle. The exception to this may be end-user documentation that may be delivered later in the project life cycle. Since PowerBuilder requires specific runtime for DLLs, and external resources to be available as part of the end-user configuration, it is especially important that these resources be identified and frozen at this time.

8.4 Check-in/Check-out Procedures

As part of the migration to the test environment, the software must first be “checked-in” to the SCMS Repository by the developer. It is recommended that the software is checked-in and checked-out throughout initial development and migration period. No software will be migrated that is not archived in the designated tool.

26


9. Release Process

The release coordinator will be administered by function group or role (i.e. developer, tester, configuration manager, etc.), and on an as needed basis. Now that NEA software is web basic, a new release branch is created for each new major and minor release. So, for example, a new release branch is created when preparing to release version 2.0.0, or version 1.3.0. However, when preparing to release 1.3.1 (a patch-version increment), the release branch created at the time of 1.3.0 is used.If you are preparing for a branch release, then there is no release branch to create. The time at which a new release branch should be created is unclear. Generally, there is a soft schedule for releasing a new minor version every 6 months. Approximately four months after the previous minor release is a good time to start proposing a branch. It is important to remember that this is flexible and depends on what features are being developed.

10. Roles

Application Architect. An application architect coordinates all the components that make up a release and their version numbers. (The application architect referred to here is for each individual application and/or subsystem of an application (i.e. GUI, Batch)).

Change Management. Change management is responsible for the execution of the change management process. This includes operating the defined and agreed upon process, ensuring it interfaces with all other relevant processes, setting targets and reviewing the effectiveness and efficiency of the process, performing process audits, and managing the process improvement cycle.

Configuration Manager. A configuration manager controls and performs the movement of software between logical environments for a release. This person also coordinates the control of access for each environment to ensure the integrity of the application.

Database Administrator. The database administrator (DBA) is responsible for creating and maintaining the database, which includes managing both structures of the database and the data. This person approves all changes in all databases used by a release.

Developer. A developer creates software, or performs modifications to existing software that is related to a release. A developer is also responsible for unit testing, and works with other developers in mini-string testing.

Development Team Lead. The development team lead coordinates the overall development for a release of an application. This person approves all software that is migrated from the development environment. This individual is permitted to facilitate the migration software from the development stage through various stages and at the discretion of the configuration manager.

LAN System Administrator. The LAN system administrator manages and administers the LAN environment, LAN system software and hardware, security, directory structures, and LAN naming standards.

27


Lead Analyst. The lead analyst is responsible for the planning, architecture, development, maintenance, and support of commercial and in-house applications for the enterprise delivered via the web, Internet and Intranet, and/or client-server. Additional responsibilities include mentoring of junior developers, adhering to the Software Development Life Cycle (SDLC) best practices, change control policies, and SLA compliance.

QA Team Lead. The QA team lead coordinates the user acceptance testing in the QA environment. Also, this person will coordinate any other activities associated with the QA environment (i.e. end-user training.)

Release Coordinator. The release coordinator coordinates the release of a given system with other systems. This may involve a simple planning effort, or may involve the coordination of complex elements and events.

Sign-Off. Sign-Off refers to signatures that are required for approval of documents, systems, processes, or changes.

Test Team Lead. The test team lead coordinates the integrated system testing efforts for an application. The test team lead approves all software migrations to the testing environment, including database changes.

Tester. The tester performs software testing to ensure the business requirements are met and the functionality of the software performs as specified. The tester represents the business user of the software.

Tool Administrator. The tools administrator is the individual designated to oversee and administer the software development “tools” used by all applications (NEA Standard Tools - i.e. Visual Studio Team Services). The “tools” administrator will perform such functions as configuring software, ensuring that underlying components, like directories, are properly established. This person also establishes user, user access, and applications within the tool, and assisting tool users with problems and questions.

UNIX System Administrator. The UNIX system administrator manages and administers the HP-Unix environment, system software and hardware, directory structures, and UNIX naming standards.

28


Appendix A: Record of Changes

Table 7 - Record of Changes

VersionNumber

Date Author/Owner Description of Change

1.0 05/22/1997 John Dobbs Initial Version1.1 03/14/2016 Kenneth

StephensUpdates

1.1 03/14/2016 Denise Erskine Edits

1.1 05/26/2016 Kenneth Stephens

Updates: Change Build to Package Release

throughout entire document. Section 3.1 Add Beanstalk as

Configuration Repository Tool Section 7. Change Enchantment to

Package Release Section 7. Change Interim to Critical

29


Appendix B: Acronyms

Table 8 - Acronyms

ACRONYMS LISTAcronym Definition

CCCB Change Control Board

CI Configuration Identification

CI Configuration Item

SCM Configuration Management

SCMA Software Configuration Management Assistant

SCMDB Software Configuration Management Database

SCMP Software Configuration Management Plan

SCMSR Software Configuration Management System Repository

CR Change Request

CSCI Confirmation Manager Assistant

CSF Critical Success Factors

DDFF Digital Forensics Framework

DVL Development

DLMS DuShane Legal Management System

II&E Individuals and Affiliates

IDE Internet Development Environment

IST Integrated System Testing

IT Information Technology

KKPI Key Performance Indicators

NNEA National Education Association

P

30


ACRONYMS LISTPARS PAC Accounts Receivable System

PFC PowerPackaged Releaseer Foundation Class

PRD Production

PMP Project Management Plan

QQA Quality Assurance

RRCS Revision Control System

SSCR Software Change Repository

SDLC Software Development Lifecycle

SVN SubVersion

TTST Integrated System Testing

VVDD Version Description Document

31


Appendix C: Glossary

Table 9 - Glossary

Term DefinitionApproval Approval refers to the authorization required by the

designated team or function leads to approve the migration from or to their respective environments. The typical approvals are as follows:

DBA approval (any database residing in a shared environment; i.e. DVL, TEST, QA);

Development lead approval (DVL environment); Production management approval (production sign-

off by the production environment management responsible for distributing software).

SAT approval (SAT sign-off by tester); Test lead approval (TEST or QA environment); and Training approval (sign-off by ?); User approval (production sign-off by the business

user).

Baseline A baseline specifies a product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. A baseline can also be a document or a set of such documents formally designated and fixed at a specific time during the life cycle of a configuration item. It can be any agreement or result designated and fixed at a given time, from which changes require justification and approval. Finally, a baseline is a configuration identification formally designated and applicable at a specific point in the life cycle of a configuration item.

Packaged Release A Packaged Release is an operational version of a system or component that incorporates a specified subset of the capabilities the final product will provide.

32


Term DefinitionChange Control Board A Change Control Board is a committee that makes

decisions regarding whether or not proposed changes to a software project should be implemented.

Change Management Change management refers to the management of information related to proposed software changes from the point of identification to the point of resolution. (See Change Management Process document).

Configuration Configuration refers to the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product.

Configuration Audit A configuration audit is conducted to verify the development of a configuration item has been completed satisfactorily, that the item has achieved the performance and functional characteristics specified in the functional and allocated configuration identification, and that its operational and support documents are complete and satisfactory. A physical configuration audit is conducted to verify that a configuration item, as built, conforms to the technical documentation that defines it.

Configuration Control Configuration control is an element of configuration management, which consists of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after the formal establishment of their configuration identification.

Configuration (or Change) Control Board (CCB)

The Change Control Board is a group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring the implementation of approved changes.

Configuration Identification Configuration identification is an element of configuration management, which consists of selecting configuration items for a system and recording their functional and physical characteristics in technical documentation.

Configuration Item (CI) A configuration item is an aggregation of hardware, software, or both, that is designated for Software Configuration Management and treated as a single entity in the configuration process.

33


Term Definition

Software Configuration Management SCM(SSCM)

Software Configuration Management is a discipline that applies technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item. Software Configuration Management also involves controlling changes to those characteristics, recording and reporting change processing and implementation status, and verifying compliance with specified requirements.

Configuration Status Accounting Configuration status accounting is an element of Software Configuration Management and consists of the recording and reporting of information needed to effectively manage a configuration task. This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes.

DIFF Digital Forensics Framework (DIFF) is computer forensics open-source software. It is used by professionals and non-experts to collect, preserve, and reveal digital evidence without compromising systems and data.

DLL A dynamic link library (DLL) is a collection of small programs that can be retrieved by a larger program that is running concurrently, as needed.

Freeze Freeze refers to the designated version or software to be used. For packaged release, a freeze will be issued on the packaged release version that is used for continued development. This will lock in the run-time DLLs need to be used in conjunction with the application, determine the PFC version, and the NEA Base Class library that should be used.

Git Git is a free and open source distributed version control system that is designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance.

Integrated System Test Integrated system testing is an application that is thoroughly tested including the verification of any applicable interfaces with other systems (Test Environment).

34


Term Definition

Migrate Migrate is a term that refers to the process of promoting and moving application software from one of the four established environments to another.

Migration Request A formal migration request refers to promoting and migrating application software or database changes from one of the four established environments to another. The request, whether automated or paper based, will provide mechanisms for the approval of the migration. A migration request is used for software, database components, or database data.

PowerBuilder Foundation Class (PFC)

The PowerBuilder Foundation Class (PFC) was introduced with PowerBuilder 5 and enhanced in PowerBuilder 6. PFC is a set of PowerBuilder objects that provide the basis for developing robust PowerBuilder applications. PFC objects provide a consistent framework that can be used across PowerBuilder applications.

Product A product is a physical entity (e.g., a piece of hardware or software) or artifact (e.g., a document) that is created by someone or a process.

Production Production is a term used to describe a live business environment.

Promote Promote refers to designating with the intent to move specified versions of software components from one environment to another as a prerequisite to actual migration.

Quality Assurance Quality assurance refers to the mechanisms (e.g., code walk through, coding standards, presentation standards, etc.) that are in place to ensure software adheres to established guidelines.

Revision Control System Utility The revision control system (RCS) utility refers to a software implementation of revision control that automates the storing, retrieval, logging, identification, and merging of revisions. RCS is also capable of handling binary files, but with reduced efficiency. Revisions are stored with the aid of the DIFF utility.

Software Configuration Management

Software Configuration Management refers to the mechanisms (e.g., version management tools, migration procedures, directory structures, user access controls, etc.) that are in place to ensure the integrity of application software components through efficient, controlled movement, and access to software between environments.

35


Term Definition

String Test A string test is a software test in which an application is thoroughly tested, including the verification of proper interactions between individual components.

System Release Migration Checklist

A system release migration checklist is a set of items that are to be performed in preparation for the release of a new production version.

Team Foundation Version Control

Team Foundation Version Control (TFVC) is a process used to scale from small to large projects, and by using server workspaces, you can scale up to very large codebases with millions of files per branch and large binary files. TFVC is a centralized version control system that enables users to apply granular permissions and restrict access down to a file level. Because a team checks work into a Team Foundation server, a user can easily audit changes and identify which user checked in a change set. By using compare and annotate tools, a user can identify the exact changes that may be needed.

Unit Test A unit test is a software test in which an individual component of an application is tested to ensure it performs the function(s) for which it was designed.

User Acceptance Test A user acceptance test is a software test in which an application is tested by representatives of the business user community to ensure the software functions in a manner that would be acceptable for execution in a live business environment (QA Environment).

Visual Studio Team Server A visual studio team server stores and collaborates on code with unlimited private repositories. Git is used for distributed version control that maximizes collaboration or uses the team foundation version control (TFVC) for centralized version control. This server assists with easily collaborating on code with pull requests and code reviews, while defining and managing permissions to secure repositories.

36


Appendix D: Referenced DocumentsTable 10 - Referenced Documents

Document Name

Description Document Location and/or URL

Issuance Date

Change Management Plan

The Change Management Plan outlines the change management process

Link to Library TBD

Software Configuration Management Software Migration Overview Charts

The SCM software migration overview charts present the individual configuration migration paths for the major NEA systems that are under development

Link to Library 3/14/2016

Developer Process Plan

The Developer Process Plan defines the development process

Link to Library TBD

Migration guidelines for NEA Production Systems

The migration guidelines for NEA Production Systems are guidelines for migrating software into the NEA production environment.

Link to Library TBD

NEA Client Server Testing Strategy Definition

The NEA Client Server Testing Strategy Definition outlines the strategy for testing client server software.

Link to Library TBD

37


https://neahq.sharepoint.com/CBO/ITS/ITSChangemngt/_layouts/15/start.aspx#/Shared%20Documents/Forms/AllItems.aspx





Document Name

Description Document Location and/or URL

Issuance Date

PowerPackaged Releaseer Promotion and Release Flow

The PowerPackaged Releaseer Promotion and Release Flow presents a detailed view of development and promotion processing for NEA projects that are built by using the PowerPackaged Releaseer tool.

Link to Library TBD

38



Appendix E: Approvals

The undersigned acknowledge that they have reviewed the Membership Software Configuration Management V1.1 and agree with the information presented within this document. Changes to this Membership Software Configuration Management V1.1 will be coordinated with, and approved by, the undersigned, or their designated representatives.

Signature: Date:Print Name:Title:Role:



39
