Commerce Administrative Management System (CAMS) Program Management Plan (PMP)

Configuration Management (CM) enables the controlled and repeatable management of CAMS-critical software and documents as they evolve in all stages of development and maintenance. CM implements a process by which the project teams and stakeholders identify, communicate, implement, document and manage changes in their configuration items. For the purposes of the NIST CAMS Implementation project, a configuration item (CI) is defined as either software or documentation that impacts the project in such a way that steps must be taken to ensure its integrity and to tracks changes made to the item. When properly implemented, CM ensures the integrity of the items that have been placed under its control.

Beginning in June 2001, the Phase III Implementation was initiated, which will expand the CAMS implementation to other organizations within NIST - including NIST, The National Telecommunications and Information Administration (NTIA), & Technology Administration (TA), with the possibility of integrating other CAMS-related modules (e.g. Travel, procurement). The Phase III goal is to have CAMS fully implemented by October 2003.

The overall goal of these CAMS implementations is to consolidate and streamline NIST financial business processes, transactions and systems to enhance internal controls and the ability to access critical data in a timely manner.

Please refer to the detailed Project Plan for additional information. The document defines and describes the project to which this CM Plan applies. The document includes the scope of the project, timetable, milestones, key deliverables, roles and responsibilities, reporting structure, and other project-specific information. The detailed Project Plan is located on the project’s LAN (Durango), under the following path: N:\CAMS\NIST Implementation\Project Plan.

The main gate is guarded by NIST Physical Security personnel and is equipped with a pass-reading system to log out-of-hours entry and exit times with the respective badge identifier. Other personnel are permitted out-of-hours access only with notification by sponsor or supervisor to the Physical Security Office. There are several cameras located at high points throughout the campus to monitor parking lots and gate activity. Physical Security personnel routinely check offices and laboratories to ensure doors are locked when not occupied. All NIST personnel are required to wear their NIST-assigned badge at all times on campus.

The CAMS development environment currently resides on a Unix server maintained by the Information Technology Lab (ITL) division of NIST. The CAMS production environment resides on a separate Unix server also maintained by ITL. Individual Implementation Team members gain access to the development and production machines via a login application using dynamic passwords. Once on the server, individuals must also pass through another layer of password encryption at the database instance level. Team members are granted access to the financial data in accordance with NIST policy and based on roles, duties, and responsibilities within the CAMS Implementation team. Banners are presented at the time of login warning the user he or she is entering a Federal government secure area and should only be used for official government business.

Users are automatically logged off the system after two hours of inactivity. Specific details of the technical architecture can be obtained as needed from the Technical Support team regarding the network environment at NIST supporting the financial processes. The development environments are backed up at least once a week, and production environment is backed up each night. All production backups are copied to 8mm tape and stored off-site weekly as a portion of the disaster recovery plan.

All team members also use a shared network drive mapped to the N: (Durango) drive residing on the local area network (LAN). This network drive serves as a repository for NIST CAMS Implementation project data. Project documentation and deliverables (except for those containing sensitive material) are stored on the shared LAN drive. All CAMS servers are behind NIST firewalls and are not currently accessible from outside the LAN network. The LAN is backed up incrementally each night.

• Review and approve the CM Plan


• Follow the CM processes and procedures outlined in this plan


• Ensure the definition and maintenance of all development processes and standards, including CM

• Identify configuration items (CIs) to be managed by the CM function


• Create, manage, maintain, and communicate the CM Plan and any CM standards and procedures to all stakeholders


• Ensure that all project team members involved in CM receive training on their roles and in how to perform their activities and how use CM tools


• Ensure that any updates to the CM Plan are communicated to appropriate project team members


• Establish project schedule for CM activities with Project Manager

• Ensure that periodic CM audits are conducted to ensure that obsolete code and tables are archived appropriately and that CM database migration procedures and change requests and approval procedures are effective. Audits will be conducted a minimum of twice per year, with archiving audits performed annually.


• Ensure that monthly CM Plan updates are conducted at NIST CAMS Implementation


• Ensure that the integrity of all Activity Requests (AR) is maintained by monitoring status of all CIs and tracking problem reports associated with them (Note: ARs are requests for coding changes to be made to the CAMS software. The NIST CAMS Implementation team is not responsible for these changes or the method in which they are made. These changes are made by the CAMS Support Center (CSC). The NIST CAMS Implementation team merely tracks the status of these requests.)


• Ensure CM activities are carried out as planned


• Track, report, and communicate CM status to the Project Manager

• Create and manage the directory and file structure, including security, residing on the NIST CAMS Implementation LAN


• Ensure that project team members have the appropriate access to the LAN

Maintain the CM Plan

• Follow the CM processes and procedures outlined in this pla
n

• Respond to requests for status regarding CM activities from managers


• Update configuration items as necessary


• Create configuration requests as necessary

• Assist CM Manager in establishing policies and procedures for CM process


• Make updates to CM Plan, as appropriate

9.7.4.1.4   Help Desk

• Receive Action Requests (AR's) from NIST CAMS Implementation Team Members


• Obtain approval for AR's before submission to the CSC


• Coordinate, and track Action Requests (AR's) between the NIST CAMS Implementation Team and the CSC.

9.7.5.1.2   Maintaining CM Plan
During the Maintaining CM Plan step, the NIST CAMS Implementation team will update and document the team's CM plan. There are two separate and distinct sets of guidelines, one for software CM and one for documentation CM. Both are included in the final CM plan. These policies do not cover pre-existing documents or software versions, except where explicitly noted elsewhere within this document.

9.7.5.1.3   Communicate CM Plan
The NIST CAMS Implementation team will communicate the CM plan to its members utilizing both written documentation and a brief training/overview session where the written documentation will be reviewed. This session will be followed by a question and answer period.

9.7.6   Document CM Process
The Document CM Plan will apply to any document that is classified as a team or project deliverable, any document that will be distributed outside of the immediate NIST CAMS Implementation team, and any internal policy and procedure document. Other documents may also be subject to this process as determined by the author or team.

This policy will only be effective for documents created after the implementation of the CM Plan. Pre-existing documents will be exempt from these rules as long as they remain unedited. Any documents that are edited after this policy is implemented shall be revised to comply with this policy. In these cases, the author/editor will make an educated guess as to the version/revision number and will begin version numbering at that point. See Section 5.1.1 for more information on naming and numbering conventions.

"NIST CAMS Implementation_<document title>_ VV.XX_ FINAL"

• <document title> equals the actual name of the document.


• V equals the version number (leading zeros should be dropped from this portion)


• XX equals the revision number.

The document title will be left to the discretion of the author. Use of spaces is encouraged for readability. However, do not use underscores within the document title portion of the name. Underscores are reserved for denoting the separation between sections of the document name.

Numbering will begin at 1.00 for a new document and will increment by one each time a change is made to either the version or revision portion of the number. When the version number (VV) changes, the revision number (RR) will be reset to zeros. (i.e.: Version 4.13 would become version 5.00 upon a version change.)

Drafts will contain the word “DRAFT” at the end of the version number. Final (approved) documents will contain the word “FINAL” at the end of the version number. The version number itself will not change when a document moves from draft status to final status. (i.e.: 3.02_DRAFT would become 3.02_FINAL upon approval.)

Version changes can and must occur within the editing cycle of a document, even before a version is accepted as a final document. In other words, if a new document is created as version 1.00 and goes through the review process, any changes made as a result of that process will be saved as a new version: 1.01.

For uniformity and readability, underscores will be used between each section of the name.

The Revision Number (RR) will reflect changes made during the editing cycle as a document goes through the editing/review process before being signed off on and finalized.

The cover page will include the following items:

• The words “Department of Commerce” centered on the page, with the words “NIST CAMS Implementation” directly below, and in a font appropriate with the rest of the document and in a large font size.


• The title of the document, bolded, all capitals, and centered on the page below the information listed in the first bullet. The title shall be in the same font and font size as the information listed in the first bullet.


• The document version number and version date on the bottom of the page, right justified, and in the same font and font size as the text of the document.

The cover page may also include (as appropriate):
• A CAMS logo
• A NIST logo
• A U.S. Department of Commerce logo
• Additional information the author deems appropriate and necessary

• Peer


• Team lead


• Government and Accenture project managers (if deemed appropriate)


• Major stakeholders (if deemed appropriate)

Signoff will be obtained at each step of the review process. This signoff will be recorded in a standardized approval block, which will be added to each document. A copy of this block can be found in Appendix B of this document. This block contains space for signoff and dating at each step of the review process. If a cover page is being used on the document, this block will be added to the second page, directly behind the cover page. If no cover page is being used, then this block will be added on its own page at the end of the document.

When a new document is created, the Document Change Log from Appendix B will be copied into the new document. If a cover page is being used on the document, this block will be added to the second page, directly behind the cover page. If no cover page is being used, then this block will be added on its own page at the end of the document. The block title, the block itself, and the instructions below it should all be copied to the new document. Instructions are provided for adding new rows as edits occur throughout the life of the document.

Please note that for the rest of this section, the word “team” will be defined as the group of users associated with the editing or use of a given document. This may be a sub-team within the NIST CAMS Implementation Team, the NIST CAMS Implementation Team as a whole, or a variation.

To allow multiple team members to edit different sections of the same document simultaneously, the following is proposed:

• When an existing document is to be edited, the editor will send an e-mail to the team advising them that the document is being edited and that no one else should make changes to the document until further notice.


• A working copy will be saved to the user’s desktop. All changes will be made to this working copy. This working copy will be used until editing is complete.


• Once the editing is complete and the new document has gone through the review process as detailed in Section 4, the new version will replace the old version in the appropriate location and the old version will be saved in an archive folder for past versions. These folders will be maintained at the team level. At no time shall an older version be overwritten or discarded.


• An e-mail will be sent to the entire NIST CAMS Implementation team, as well as any other users, advising them that a new accepted and finalized version of the document has been placed on the LAN.

9.7.11   Change Control Communication Policy
As discussed in Section 5.4, e-mails will be sent by the author/editor of a document when:

• A document is “signed out” to be edited.


• A document is returned from editing and placed back into production.


• A new document is placed into production.

The CAMS Implementation Team will rely on existing processes in place whereby ITL performs nightly backups of the server for additional archiving of documents.

After 9 months, back versions of documents will be zipped using WinZip or equivalent software. These zip files will be maintained in the appropriate “Archived Documents” folder. The purpose of zipping will be to reduce impact to server space caused by saving all back copies of all documents.

• Software Version Management


• Data Management


• Instance Management


• Database Management


• Liaison Activities

The basic tasks and responsibilities performed by the NIST CAMS Implementation team are:

• Coordinating, verifying, and installing new software releases and modifications, including NIST developed or enhanced reports


• Coordinating, verifying, altering, and adding maintenance data to the database


• Coordinating and adding instances and object owners to the database


• Coordinating the upkeep and creation of user accounts

9.7.15.1.2   Scope
This section of the CM Plan covers:

• The NIST Configuration Management Team personnel required to plan, coordinate, and execute this Configuration Management Plan


• The management, modification, and migration of all software modules associated with the CAMS character and GUI versions, and interfaces


• The static and dynamic data contained within the databases supporting the CAMS application


• The Oracle databases and instances contained within the CAMS application

For the NIST implementation and production support activities, changes to the software may be requested from the members of the NIST CAMS Implementation team, as well as from the client. The NIST CAMS Implementation team is not responsible for the primary development or enhancements of the software used at NIST at this time. These changes are handled by the CAMS Support Center (CSC). Further, the NIST CAMS Implementation team has no control over the CSC’s version control and configuration management processes.

• The initial planning of features that must be included in the release


• Verifying that all components that constitute the release have been delivered, and packaging them together


• Ensuring compatibility between the constituent components

Product delivery can be accomplished by overlapping multiple releases. Synchronization between multiple releases must be accomplished through special Change Control procedures to ensure that module changes and enhancements are properly integrated into the CAMS system and made available to the appropriate functions in a controlled and orderly fashion.

Insufficient release management control leads to prolonged release periods and inconsistent system outputs, as incompatible components are discovered and must be replaced with the correct ones during the release process. Poor release management also increases the time required for testing and validation efforts as scripts must be re-run in order to verify expected results.

• Automatic and manual procedures will deliver and install software on the proper hardware units.


• The installation procedure will include removal of the older version of the same product if necessary.


• In case a partial release (such as a patch) is needed, the installation procedure will verify the compatibility of the new components with the already installed release.

Well-defined software distribution procedures are always important, ensuring consistency in system functioning, reducing the effort required for regression testing, and gaining end-user confidence in the overall functioning of the system, CAMS in this case, and in the ability of the software provider to provide a quality product.

Version Control accomplishes several functions:

• It facilitates the development process by supporting efficient restoration of an application's prior development stages.


• It facilitates the maintenance process by leaving an accurate modification history.


• It provides a simple way to check on the status of changes and versions.

In the NIST CAMS environment, version control can be viewed as the management of each particular module as it is upgraded, modified, or enhanced, and how that module is tracked in the system. For instance, if FM030 was modified (re-worked) four times in the past year, it would be tracked in version 1.153.1.0, 1.153.1.1, 1.153.1.2, and 1.153.1.3. When a new version is received, it is assigned the next available version number based on the version numbers already assigned and stored in this location.

NIST releases:
Each report/interface delivery has a version number that is comprised of the word “NST1” followed by .000. The last digit is incremented by 1 for each release, rework or enhancement. For example, NST1.000 is the first release and subsequent releases are numbered NST1.001, NST1.002, NST1.003, and so on. If the NST1.002 introduces rework, it will be NST1.004, .5, .6 and so forth depending on the current version.

1) CAMS Implementation Team Software Configuration Manager – A NIST position that performs the oversight function for software configuration management and for planning and implementing tasks such as database management and software release management.

2) CAMS System Administrator - Position within NIST operations performing support/maintenance functions relating to screen access, usernames/passwords and security privileges.

3) CAMS DBA - Position within NIST, performing support/maintenance functions relating to the CFS databases, and software applications.

4) Database/Instance Owners – NIST on-site positions that evaluate and approve/deny all formal requests for changes, updates, and usage requests for their respective environment

5) NIST Developers – NIST reports and Interface developers enhancing or creating character based or GUI-based programs and reports.

6) CAMS Implementation Team - NIST on-site functional and technical positions supporting CAMS/CFS users and interface with the CAMS DBAs. These roles serve as first points of contact for questions relating to CFS user navigation, setup, configuration, and as a reference point for technical problems.

7) WAN/LAN Administrator - NIST on-site positions that establish and maintain the in-house Local Area Network, and user connectivity.

8) CAMS Help Desk - NIST on-site personnel receiving and troubleshooting calls from CAMS Production users.

9) PC Support – NIST on-site positions that support the workstations and assist in problem resolutions.

• Enforce software consistency in all development and testing environments


• Facilitate the controlled and coordinated movement of modules between the staging, development/testing, and production environments


• Ensure that version control is enforced through a standard software tracking and documentation process

• Receiving and installing CAMS software release from CSC


• Managing software versions within each code directory


• Migration of CAMS software through the implementation lifecycle (staging, testing/development/training, production)

• The flow of software between each of the four life cycle stages (i.e. development, staging, test, pre-production, and production)


• The relationship with regard to code version among instances


• The function of each instance based on its code concepts (This will be covered in detail in the Instance Management section)


• The logical associations for testing activities and control thereof

Each of these versions labeled one through four in the picture above are associated with one or more instances. The flow of the software between these three locations is called the CAMS Software Migration Process. A brief description of each of the three environments follows as well as the processes in place to organize and orchestrate software migration between the instances.

Playground This environment serves as a repository where interface developers conduct unit testing.

Staging Server The staging server contains all versions of code received by the system administrator from the CAMS Support Center, and interfaces and reports developed by CAMS Implementation Team. It is a central repository for all code that is forwarded to the DBA team.

Testing, Development I & II Environments The testing environment houses the version of code that is being unit and integration tested for production readiness. Reports and Interfaces flow from Playground to Staging repository to Development II for a stable unit testing to Testing for integration testing, and finally to Production.

Pre-Production Final integration testing environment before production.

Production The production environment contains the latest version of the CAMS Software code that has been tested and approved for migration to production by the CAMS Integration Team. The training environment is currently being used for CRP.

Post-Production The post-production environment is a mirror copy of production - same version of code and database data – in any given 24-hour period.

Conversion, Migration, Training The migration environment exists to support GUI AR testing.

Conversion, Migration and Training environments are currently not in the direct software flow.

1. Release code from the CSC –The CSC is sends each code to the CAMS System Administrator. The System Administrator is responsible for performing an initial analysis of the impact this release will have on production.

2. In-House Developed Reports and Interfaces – The Database Owner sends each report/Interface developed or enhanced by the NIST Implementation Team to the CAMS SCM team. Please refer to appendix C for a detailed checklist on Nist reports.

3. Inform Configuration Management Team of software release - The System Administrator forwards the details of the software release to the Configuration Management Manager for her review via a Remedy request. The request is subsequently sent to the CM team to review the release and perform their analysis of the production impact of this release.

4. Migrate new code release to the Staging repository - After the members of the Configuration Management team have reviewed the release specifications, the DBA will copy this new software release to the Staging server (as defined above).

5. Update release management spreadsheet - The CAMS Implementation team keeps a detailed spreadsheet of each release. This spreadsheet is used to assist in the creation of migration and integration plans. In addition to the CAMS Implementation team’s spreadsheet, the DBA team keeps a record of each version of code as it is applied to the environment.

6. Migrate all versions and releases up to a pre-selected point to the Testing/Development Environment - At a given point, the CAMS Implementation Team makes a decision to migrate a version of code and all predecessors to the testing environment. This decision can be based on several factors and they include, but are not limited to the delivery of core functionality, the repair of a severity one activity request or the scheduled release of production software. When this decision is made, the database administrator migrates the selected code to the Testing/Development Environment (as defined above).

7. Perform Integration/Regression testing - The Integration Testing team performs a detailed integration/regression-testing cycle. This cycle focuses on sport checking each code change applied to the environment in addition to regression testing some base functionality currently used in production.

8. Document the results of Integration/Regression testing - Upon the completion of the integration/regression testing effort, the Testing team will document all of their findings and the results of each test. In addition to these results, this document also contains the inherent risks, if there are any, with the migration of this version of code to production.

9. Make go/no go decision - The CAMS Implementation Team is responsible for taking all information into consideration and determining the best course of action with this software release. Several factors will be considered in this decision. Some of these factors are the risks uncovered in Integration Testing, the potential impact on the production environment and the benefits that could be realized with the migration. If the decision is not to migrate the code, a new plan must be created, a new code version identified and the team will return to step five in this process.

10. Create a production migration plan - After the implementation team reaches the go decision, the team will work with the database administrator to create a plan to migrate this code to production. This plan is critical, as system downtime will be encountered during the migration effort.

11. Point tested code to Training Instance - Once the go decision has been made, the database administrators will point the tested code to the training database.

12. Conduct any training of end-users - The CAMS Implementation team will conduct any training that must be completed before the new code can be migrated to production. This is critical because the users will find different functionality and performance when they return to work on a Monday. This training will assist in a seamless transition between the two versions.

13. Perform Database and Code Directory backup - Before the migration effort can take place the database administrators will perform a full production database backup as well as a backup of the production code directory. This will be used to rollback to the existing production code and database structure in the event that something goes wrong during the migration effort.

14. Refresh Pre-Production Database – The database administrator at the request of the system administrator will refresh the pre production instance using the most recent production backup. In most cases that backup will be from the close of the previous business day.

15. Migrate all database changes to the Pre-Production Database - The database administrators will apply all database changes to the pre prod database. The pre prod database will be used to test the migration of the application code so it is critical that the pre prod database is up to date with the migrated code version.

16. Perform selected tests in the Pre-Production Environment - The CAMS Implementation Team will perform a series of pre-selected scripts in the pre production environment. Since the pre production code is the same code version as production, this test will confirm the success of the migration effort. In addition the database and the data contained within it is also as a direct copy of production. This fact further validates this test as a true test of the production migration.

17. Migrates tested code to Production - Assuming all pre-prod testing is successful, the database administrators, with the support of the CAMS Implementation team will migrate the tested code to production. If no errors are encountered the DBAs will alert the implementation team that the code release has been completed successfully.

18. Inform end-users - It is important to inform the end users that changes have been made to the production version of the code. The sharing of this knowledge will assist the implementation team in two ways. First the end users will not be surprised with new or enhanced functionality. And more importantly, the end users will be able to determine if any functionality is incorrect or performing poorly.

19. Copy code/data to Post-Production – Post–prod instance is updated with the latest code within 24 hours of production implementation. In addition, production data is also copied into the environment.

Note: All requests to SCM and DBA teams are made via Remedy Action Request System.