Report includes, but not limited to: Pest, swot, and 5 Forces analysis, as well as summary of business operations, assets (tangible and intangible) and suggestions & recommendations for the company based on opportunities for future growth and development of the business.
Report includes, but not limited to: Pest, swot, and 5 Forces analysis, as well as summary of business operations, assets (tangible and intangible) and suggestions & recommendations for the company based on opportunities for future growth and development of the business.
Social media project consisting of strategic digital marketing strategies and several recommendations for an insurance broker completed by students at the University of Washington Tacoma.
This document was developed to assist a local government create a change management plan to upgrade processes and systems within their organization and to improve the efficiency of standard business practices.
Getting started with mca reports (in xbrl format) | Tally Corporate Services ...stannventures.Pvt.Ltd
For more information about this PDF file. Please visit http://www.tallyspot.com
Ideal spot for a obtain Tally 9 ERP and download free Tally.ERP 9 versions. Up-grade Tally
Accounting Software & .NET Subscription, Advanced Web Interface Accounting Software for Asia & Most
ERP Software Products. Import data from tally & Data Connectivity to Tally.ERP 9 Import.
MarvelSoft LibraryAdmin helps schools to manage their library. You can maintain book stock details, borrowers details, due dates, books bard code labels, issue / return books from students and staff. generate various MIS reports
Social media project consisting of strategic digital marketing strategies and several recommendations for an insurance broker completed by students at the University of Washington Tacoma.
This document was developed to assist a local government create a change management plan to upgrade processes and systems within their organization and to improve the efficiency of standard business practices.
Getting started with mca reports (in xbrl format) | Tally Corporate Services ...stannventures.Pvt.Ltd
For more information about this PDF file. Please visit http://www.tallyspot.com
Ideal spot for a obtain Tally 9 ERP and download free Tally.ERP 9 versions. Up-grade Tally
Accounting Software & .NET Subscription, Advanced Web Interface Accounting Software for Asia & Most
ERP Software Products. Import data from tally & Data Connectivity to Tally.ERP 9 Import.
MarvelSoft LibraryAdmin helps schools to manage their library. You can maintain book stock details, borrowers details, due dates, books bard code labels, issue / return books from students and staff. generate various MIS reports
Assignments on adopting information technology in traditional organisationsMukalele Rogers
This document contains answers to BIT 1106 – INTRODUCTION TO INFORMATION TECHNOLOGY Phase one assignment as given at Makerere University Jinja Campus. Questions covered include:
1. The terms Information Age and Information Society are frequently associated with applications of information technology. How do the meanings of the two terms differ with respect to Information technology? 4
2. Explain the statement: The information Age does not replace the activities of earlier ages. It transforms them. 5
3. ‘Know-how’ is neither a computer nor a communication network. Why, then, is it a component of Information technology. 7
4. How does Incorporating I.T in a business improve customer service? 8
5. Make notes about Classification of systems: Abstract, Open, Closed, Deterministic, Probabilistic, Cybernetic, Open loop, Closed-loop, Artificial, Human-machine, Information, Management Information systems. 12
i. Abstract Systems 12
ii. Open systems 12
iii. Closed systems, 12
iv. Deterministic systems, 12
v. Probabilistic systems, 13
vi. Cybernetic systems, 13
vii. Open loop systems, 13
viii. Closed-loop systems, 14
ix. Artificial systems, 15
x. Human-machine systems, 15
xi. Information systems, 15
xii. Management Information systems. 15
6. What is the difference between a Laptop and a PDA? 16
7. What are Supercomputers and where are they used? 17
8. A Workstation is an exaggerated Microcomputer, discuss. 18
9. What factors should a user consider while choosing a type of Computer for a given Institution? 21
ASSIGNMENT TWO 23
1. Explain the importance of information for communication purposes. 23
2. Describe the importance of information for decision making. 24
3. Explain the importance of information for understanding and reacting to the environment. 25
ASSIGNMENT THREE 26
1. What is a query? What purpose does it serve? 26
2. Why is the ability to integrate databases valuable in problem solving? 27
3. Why should redundancy in databases be managed? 28
4. In what ways can databases change? 29
5. Identify when a business should use a spreadsheet and when it should use a database. 30
6. Why are databases shared? 32
7. Discuss the relationship between an entity relationship model and the schema for a relational database. 33
8. What is the function of index? 34
9. Describe the relation between client/server computing, communication networks, and shared databases. 35
10. Describe 6 areas of responsibility in data administration. 37
RF card terminal user manual in which we have mentioned how to register and delete the people from device and other fnctions too, this will be a great help for our end users.
5. ii
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 ...............................................................................................................................3
Figure 2 - Impact Analysis Functionality Process......................................................................................................20
Figure 3 - CI for Hardware/Software Systems .........................................................................................................22
Figure 4 - Configuration Audit Process Flow.............................................................................................................24
Table of Tables
Table 1 - Configuration Products.................................................................................................................................12
Table 2 - Software Configuration Management Process........................................................................................14
Table 3 - Roles and Responsibilities............................................................................................................................15
Table 4 - Document Revision History .........................................................................................................................17
Table 5 - Release Numbering.......................................................................................................................................18
Table 6 - NEA Configuration Items..............................................................................................................................24
Table 7 - Record of Changes.........................................................................................................................................30
Table 8 - Acronyms........................................................................................................................................................31
Table 9 - Glossary...........................................................................................................................................................33
Table 10 - Referenced Documents .............................................................................................................................38
6. 1
Software Configuration Management Plan
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
7. 2
Software Configuration Management Plan
this SCMP, Configuration Identification includes the selection, creation, and specification of the
following:
Products that are delivered to the client
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
8. 3
Software Configuration Management Plan
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 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
9. 4
Software Configuration Management Plan
2.1 Roles and Responsibilities
Only the responsibilities related to SCM are listed here.
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;
10. 5
Software Configuration Management Plan
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;
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;
11. 6
Software Configuration Management Plan
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)
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
12. 7
Software Configuration Management 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
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
13. 8
Software Configuration Management Plan
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
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 Roles
DTMB Agency Service (AS) Client Service Director
(CSD)
Stakeholder
Application Development Functional Manager(s) Development Manager(s)
Client Support Specialist Client Support
Infrastructure Specialist Agency Services Support
Configuration Management Manager (CMM) Service Provider
Subject Matter Expert(s) (SME) Subject Matter Expert(s)
14. 9
Software Configuration Management Plan
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:
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
15. 10
Software Configuration Management Plan
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.
Configuration Items
Description/SUI
TE 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
16. 11
Software Configuration Management Plan
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;
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.
17. 12
Software Configuration Management Plan
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
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. Control
From 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.
18. 13
Software Configuration Management Plan
3.5 Identification
The 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 Planning
The 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 Accounting
The 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.
3.8 Verification and Audit
The 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 Assumptions
The 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;
19. 14
Software Configuration Management Plan
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%.
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 & Techniques
N/A JIRA
N/A Visual Studio Team Service
NA SharePoint
Table 2 - Software Configuration Management Process
20. 15
Software Configuration Management Plan
5.2 Roles & Responsibilities
The roles and responsibilities for Software Configuration Management are defined in the NEA
Project Management Plan.
Name Role Responsibility
Kenneth Stephens Software Configuration
Management & Release
Coordinator
N/A
Table 3 - Roles and Responsibilities
5.3 Environment
Development (Development Testing - DVL)
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)
21. 16
Software Configuration Management Plan
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.
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.
22. 17
Software Configuration Management Plan
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:
CR#
(optional)
Document
Version #
Approval Date Modified By
Section, Page(s), and
Text Revised
1.0 Initial Submission
Table 4 - Document Revision History
Releases
As 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 number
YY = point release number
ZZ = change number
BB = Packaged Release number
a = emergency
23. 18
Software Configuration Management Plan
An explanation of the numbering format is provided in Table 3-4 Release Numbering.
Name Definition Sample Value
Version 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
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
24. 19
Software Configuration Management Plan
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 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.
25. 20
Software Configuration Management Plan
Figure 2 - Impact Analysis Functionality Process
6.6 Tracking & Controlling Changes to CI Baseline
The 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
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;
26. 21
Software Configuration Management Plan
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.
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.
27. 22
Software Configuration Management Plan
6.7 Configuration Integrity
Ensuring 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:
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.
28. 23
Software Configuration Management Plan
6.8 Configuration Status Accounting
Software 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 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:
29. 24
Software Configuration Management Plan
Baseline Configuration Item Control When Baselined
Functional Requirements Document Formal Requirements Sign-off
Project Work Plan Informal Requirements Sign-off
Allocated Design Document Informal
Software Configuration
Management Plan
Formal NEA Director Sign-off
Table 6 - NEA Configuration Items
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.
30. 25
Software Configuration Management Plan
7. Description of Release Types
Application 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 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 Sample
Release Number Example: 1.0.3.4
Where 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
31. 26
Software Configuration Management Plan
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 Control
The 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;
Change requests approvals;
Configuration control tools and techniques;
Management of release documentation;
No change is made to the product baselines without authorization;
Procedures for changing baselines; and
The latest approved version of the product and its components are used at all times.
8.1 Configuration Accounting
Software 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
32. 27
Software Configuration Management Plan
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.
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)).
33. 28
Software Configuration Management Plan
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.
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.
34. 29
Software Configuration Management Plan
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.
35. 30
Software Configuration Management Plan
Appendix A: Record of Changes
Table 7 - Record of Changes
Version
Number
Date Author/Owner Description of Change
1.0 05/22/1997 John Dobbs Initial Version
1.1 03/14/2016 Kenneth
Stephens
Updates
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
36. 31
Software Configuration Management Plan
Appendix B: Acronyms
Table 8 - Acronyms
ACRONYMS LIST
Acronym Definition
C
CCB 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
D
DFF Digital Forensics Framework
DVL Development
DLMS DuShane Legal Management System
I
I&E Individuals and Affiliates
IDE Internet Development Environment
IST Integrated System Testing
37. 32
Software Configuration Management Plan
ACRONYMS LIST
IT Information Technology
K
KPI Key Performance Indicators
N
NEA National Education Association
P
PARS PAC Accounts Receivable System
PFC PowerPackaged Releaseer Foundation Class
PRD Production
PMP Project Management Plan
Q
QA Quality Assurance
R
RCS Revision Control System
S
SCR Software Change Repository
SDLC Software Development Lifecycle
SVN SubVersion
T
TST Integrated System Testing
V
VDD Version Description Document
38. 33
Software Configuration Management Plan
Appendix C: Glossary
Table 9 - Glossary
Term Definition
Approval 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).
39. 34
Software Configuration Management Plan
Term Definition
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.
Change 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.
40. 35
Software Configuration Management Plan
Term Definition
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.
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.
41. 36
Software Configuration Management Plan
Term Definition
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).
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.
42. 37
Software Configuration Management Plan
Term Definition
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.
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).
43. 38
Software Configuration Management Plan
Term Definition
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.
Appendix D: Referenced Documents
Table 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
44. 39
Software Configuration Management Plan
Document
Name
Description Document Location
and/or URL
Issuance
Date
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
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
45. 40
Software Configuration Management Plan
Appendix E: Approvals
The undersigned acknowledge that they have reviewed the Software Configuration
Management Plan and agree with the information presented within this document. Changes to
this Software Configuration Management Plan will be coordinated with, and approved by, the
undersigned, or their designated representatives.
Signature: Date:
Print Name:
Title:
Role:
Signature: Date: