NRC-HQ-11-R-33-0011.(2.25.2011).doc

NRC-HQ-11-R-33-0011

Section B

PART I - SCHEDULE

SECTION B - SUPPLIES OR SERVICES AND PRICE/COSTS

B.1 PRICE/COST SCHEDULE

In its proposal, the offeror shall provide fully loaded hourly labor rates for the individual Functional Area (FA) required labor categories for the following contract periods:

001 Base Period – The base period of performance is 12 months from the date of award.

002 Option Period I – One year, beginning on day after Base Period expires.

003 Option Period II - One year, beginning on day after Option Period I expires

004 Option Period III - One year, beginning on day after Option Period II expires.

005 Option Period IV - One year, beginning on day after Option Period III expires.

006 Option Period V - One year, beginning on day after Option Period IV expires.

007 Option Period VI - One year, beginning on day after Option Period V expires.

008 Award Term I - One year, beginning on day after Option period VI expires.

009 Award Term II - One year, beginning on day after Award Term I expires.

010 Award Term III One year, beginning on day after Award Term II expires.

B.2 PROJECT TITLE

The title of this project is as follows: Maintenance, Operation, and Modernization Support of U.S. Nuclear Regulatory commission Application Systems and Environment (“MOM”) Acquisition

B.3 BRIEF DESCRIPTION OF WORK (MAR 1987) ALTERNATE 1 (JUN 1988)

(a) Brief description of work:

The objective of this acquisition for “Maintenance, Operation, and Modernization Support of U.S. Nuclear Regulatory Commission Application Systems and Environment” is to procure continuous maintenance and operational Information Technology (IT) support services for current and future NRC automated computer systems. This acquisition will also provide modernization support services while replacing legacy technologies with secure, innovative, enterprise-wide IT solutions. This acquisition focuses on both enterprise and service level requirements for IT services.

B.4 AWARD TERMS

(a) The Contractor’s performance will be measured against the negotiated elements and performance levels as prescribed in the Award Term Plan (“Plan”) (Attachment D), by the Performance Award Term Review Team, who will report their findings to the Award Term Determining Official. The Award Term Determining Official makes the final decision regarding whether award term(s) will be granted according to the criteria set forth in the Award Term Plan.

(b) In addition to the criteria set forth in the Award Term Plan, the exercising of Award Terms is at the unilateral discretion of the Government subject to (1) the availability of funds in accordance with FAR clause 52.232-19, (2) the Government’s continued requirement of the services, and (3) at no time during the performance of this contract, the Contractor receives an interim past performance rating for the preceding contract years below a satisfactory rating from NRC.

B.5 CONTRACT TYPE

This is an Indefinite-Delivery, Indefinite-Quantity (IDIQ) contract under which firm-fixed-price, time-and-materials or labor-hour task orders may be negotiated and awarded.

B.6 DURATION OF CONTRACT PERIOD (MAR 1987)

The duration of the is contract is a one year base period and nine (9) one-year options to extend the term of the contract. The last three options are award term options.

B.7 CONTRACT CONSIDERATION AND MAXIMUM CONTRACT VALUE

The Government is obligated to order a minimum of $5,000.00 worth of services during the first 12 months of the Base Period of this contract. The maximum value for this acquisition is $240,000,000.00, considering all five functional areas identified in the solicitation and considering all awardees under the five functional areas. There is no maximum value per functional area or maximum value per awardee, and the Government may order up to the maximum value over the duration of this acquisition. As task order(s) are awarded under this acquisition, the maximum amount remaining under this acquisition will be reduced by those award amounts. As amounts are deobligated on those task orders, the maximum amount remaining under this acquisition will increase accordingly.

SECTION C - DESCRIPTION/SPECIFICATIONS/STATEMENT OF WORK

Overview

C.1.1 Background

The U.S. Nuclear Regulatory Commission (NRC) was created as an independent Agency by Congress in 1974 to enable the nation to safely use radioactive materials for beneficial civilian purposes while ensuring that people and the environment are protected. It regulates commercial nuclear power plants and other uses of nuclear materials, such as in nuclear medicine, through licensing, inspection, and enforcement of its requirements. The NRC’s headquarters are in Rockville, Maryland, and there are a number of other offices around the United States.

C.1.1 Objectives

The objective of this acquisition for “Maintenance, Operation, and Modernization Support of U.S. Nuclear Regulatory Commission Application Systems and Environment” (also referred to as “MOM”) is to procure continuous maintenance and operational Information Technology (IT) support services for current and future NRC automated computer systems. This acquisition will also provide modernization support services while replacing legacy technologies with secure, innovative, enterprise-wide IT solutions. This acquisition focuses on both enterprise and service level requirements for IT services. The modernization support services and replacement of legacy technologies will help reduce maintenance and operation (M&O) costs while achieving the goals stated in Section C.

C.1.1 Specific Service Objectives

The NRC currently has approximately 100 computer-based application systems that require MOM support services. These systems are generally managed by separate NRC organizations responsible for related functional use and system operation. In addition, the NRC anticipates adding approximately three new application systems each year over the duration of this contract.

The NRC has the following goals for this acquisition:

a) Establish secure, enterprise-wide, and standardized IT solutions

b) Maximize flexibility, agility, and innovation in IT service delivery

c) Deliver reliable, high quality, and cost effective IT solutions

d) Create effective IT governance where appropriate

e) Enable the NRC to more effectively meet its mission

C.2 Maintenance, Operations and Modernization C.2.1 Maintenance NRC’s application system maintenance is defined as modification and/or correction of application system code and/or data to make the application system perform as intended in support of the business process for which the code was written. These modifications may include those made to programs, scripts, job control languages, and data. Maintenance also includes, but is not limited to, analysis of conditions and outputs to identify root causes of problems and define methods for correction by troubleshooting, executing backups, restoring archives, and housekeeping.

Maintenance may take the form of preventive, corrective, adaptive, or perfective actions or any combination of these actions.

a) Preventive Maintenance – identify potential future faults and modify the system to mitigate the risk

b) Corrective Maintenance – identify current system faults and modify the system to fix them

c) Adaptive Maintenance – modify the system to maintain compliance with changing IT infrastructure, IT security requirements, and technology upgrades

d) Perfective Maintenance – modify the system to add new or improved functionality

C.1.1 Operations The primary goal for the operation function is to manage and support NRC’s software in a production environment. The focus of operations is to ensure that software is running properly and that the appropriate data is backed up and restored as needed. Disaster recovery plans are created and, in the event a disaster occurs, are executed to restore primary systems. The focus of operational support is to assist end users by answering their questions, analyzing the problems they are encountering with production systems, recording requests for new functionality, and making/applying fixes.

The contractor shall keep systems running, back-up and restore data based on the operations plan and system requirements, manage problems, performing periodic cleanup, fine tune system reconfigurations, monitor systems, and redeploy systems as necessary.

Contractor operational support may take various forms including, but not limited to, the following:

a) Data Support – perform data entry, interpretation, scanning, and verification

b) Report Generation – produce standard and ad hoc reports

c) Production Support – perform data transfers, system monitoring, and troubleshooting

d) Test Support – perform application testing in accordance with testing procedures contained in the Project Management Methodology (PMM) and Test Management Guide

e) Plan for Disaster Recovery – define and update steps for staff to follow to achieve critical system back up and operation in the event of catastrophe

f) Disaster Recovery– maintain, store, and execute the Disaster Recovery Plan to ensure timely recovery of critical systems

C.1.1 Modernization

Agency system modernization support is a proactive approach to managing the ongoing evolution of business processes and systems, while focusing on achieving an optimized IT environment for value, cost, and risk.

Many outdated legacy systems will be on unsupported software during the period of performance of this contract and therefore modernization activities must be executed. The NRC will review the current IT environment to identify outdated or unsupported application systems for modernization.

To facilitate optimum business processes and systems, modernization may take the form of application improvement, language-to-language conversion, platform migration, consolidation, or any combination of the following activities:

a) Application Improvement – improve the robustness, integrity, quality, consistency, and/or performance of a system

b) Language-to-Language Conversion – convert an application from one computer language to another computer language

c) Platform Migration – move a system from one computer platform to another computer platform

d) Consolidation – combine two or more systems into one

C.2 NRC Segment Architecture

The NRC continues to mature its Enterprise Architecture (EA) to help achieve its mission goals of nuclear safety, nuclear security, and operational excellence. To effectively manage the complexities of architecting the enterprise, the NRC uses the Office of Management and Budget’s (OMB) segment architecture approach to analyze similar business functions within the agency, based on a framework and vocabulary common across the Federal Government.

The NRC has defined 14 segments that are divided into core mission areas that align to the major business functions of the organization, as well as the business and enterprise service areas necessary to maintain operational excellence. NRC system architecture can be seen in Figure 1 below.

Figure 1: NRC Segment Architecture

This NRC segment architecture will be utilized during performance of MOM task orders to group application systems into the appropriate segment. To insure greater consistency among NRC application systems, the NRC segment architecture will allow MOM contractors to focus on a group of related NRC application systems while providing M&O support to legacy systems, developing requirements and design, modernizing legacy systems, and providing M&O support for the modernized systems.

C.3 Functional Area Requirements

The solicitation requirements have been broken down into five functional areas (FAs) in order to ensure superior maintenance, operations, and modernization support for NRC application systems. The NRC anticipates awarding separate Indefinite- Delivery, Indefinite-Quantity (IDIQ) contracts under each of the following five functional areas.

e) FA1: Centralized Environment Support (full and open competition resulting in one award)

f) FA2: M&O of Legacy Systems (full and open competition with potential for multiple awards)

g) FA3: Requirements and Design (full and open competition with potential for multiple awards);

h) FA4: Legacy Modernization and New Software Application Development (small business set-aside with potential for multiple awards)

i) FA5: M&O of Modernized Systems (small business set-aside with potential for multiple awards)

These functional areas all play an important role in the success of this acquisition. Contractors under this acquisition shall ensure open communication between all functional areas in order to seamlessly provide maintenance, operations, and modernization support. Figure 2, below, shows the flow of information between contractors in each of the five functional areas. The NRC will interact directly with contractors in each of the five functional areas. Contractors for FA2, FA3, FA4 and FA5 shall all work within the development and testing environments provided by the FA1 contractor.

INTENTIONALLY BLANK

Figure 2: MOM Interactions between Functional Areas

The following sections describe each of the five functional areas in more detail. More detailed requirements for each functional area will be specified in the performance work statement for each individual task order.

C.3.1 FA1: Centralized Environment Support

This functional area requires the contractor to provide the development and test environments to be utilized by each contractor that receives an award under this acquisition. The development and test environments shall simulate the NRC’s IT environment. The FA1 contractor shall provide high-speed (something other than dial-up) internet access and a Virtual Private Network (VPN) connection to other awardees under this acquisition for development and test efforts. Contractors in the other four functional areas are responsible for implementing and funding their own high-speed access and VPN connection in order to access the NRC Centralized Environment.

This FA may also include requirements for non-standard technologies (outside of what is in Appendix F) for engineering technical services that need to be introduced for modernization.

Figure 3 provides a high level illustration of how the FA1 contractor will interact with the NRC, as well as with contractors in other functional areas (FA2, FA3, FA4 and FA5).

Figure 3: MOM Centralized Environment Overview

C.3.1.1 Government Furnished Equipment

For physically based hosting solutions, the NRC will provide all equipment and server software (except for access specific software) required for the centralized environment infrastructure. If a cloud based solution is proposed, then the Government will only provide server software if appropriate. Additional Government Furnished Equipment (GFE) may be provided for individual task order requirements.

C.3.1.2 System Administration Support

a) The contractor shall provide on-site application systems administration system support.

b) The contractor shall provide hardware administration, configuration, and software installation and deployment support including application support. Support developers and testers in the activities associated with design, code, test, debug and documentation of applications and administration. Provide access controls in accordance with Agency procedures and maintain and review audit logs. Work at the highest technical level of all phases of system administration, system engineering, access control, and security control. Ensure operational availability of the centralized environment in accordance with the performance metrics defined in Appendix D.

C.3.1.3 Place of Performance

The anticipated place of performance shall be at the contractor site and/or Government sites in Rockville, MD. The FA1 contractor site and their deployed resources must be within a ten mile radius of the NRC Headquarters Building (11555 Rockville Pike, Rockville, MD 20852) and be within Montgomery County, Maryland.

C.3.1.4 Centralized Environment Support

In the accomplishment of its mission, NRC utilizes a wide diversity of general purpose digital computers ranging from servers to desktop workstations. These systems, while diverse in capability, are functionally interoperable through their support of IP networking and interoperability standards. These systems provide source code and application interoperability and portability through their support of the applications development and testing with other IT standards and alternate operating systems, such as Windows and Linux. They allow users to move between machines in a heterogeneous networked environment while maintaining an interoperable user environment. The FA1 contractor shall host IBM Rational tools (Rational Enterprise Suite and Rational Jazz Platform) to be used by FA2, FA3, FA4, and FA5 contractors to perform development and testing activities.

a) Software Support

Software support service shall only be applicable to software provided as GFE under this contract. Software support shall consist of correction or updates revisions through software patches, software upgrades, and technical support for problem resolution of operating systems and the development tools in the JAVA or .Net platform suites or any software located in the centralized environment. The FA1 contractor shall only make changes to the development and test environments after an approved change request has been issued from the NRC Project Officer (PO) for the FA1 contract.

b) Software Patches

Software patches are modifications to the software that provide fixes to address security issues and known problems. The contractor shall provide software patches to all end users through on-line access.

c) Technical Support

The contractor shall provide technical support to NRC end users and, as applicable, other contractors supporting NRC. This technical support shall be provided, at a minimum, from 8:00 a.m. to 6:00 p.m. (Eastern Time), Monday through Friday (excluding Government holidays and other days when NRC is closed). Technical support may include, but is not limited to, the following:

i. Access support to environment

ii. Telephone support or support located within the centralized environment

iii. Developer and tester support

iv. Deployment support

v. Configuration and change management support

vi. Troubleshooting

vii. Backups

a) Software/System Deployment Support

Applications and systems that are new, undergoing maintenance, enhancement or modernization, must follow a formal configuration/change management (CM) process to ensure proper controls over scope, performance, quality, and security management of the application system. Separation of duties between the application/system personnel and CM personnel is necessary to ensure consistency of controls and the quality of baselines that are migrated between environments.

Therefore, the contractor shall support NRC PO and their designees in promoting approved system baselines between environments. The contractor shall provide technical support for the change impact and risk evaluations as part of the NRC CM process. Ensure development and test environments are kept in synch with the current CM baseline definitions. The contractor shall use IBM Rational tools and formal CM processes (described in Section C.5.2) to manage stable baselines and change requests. The contractor shall follow this same CM process to manage the environment infrastructure changes.

C.3.1.5 Development Environment

Objective – New IT applications and systems are regularly brought into the NRC production environment. These are either custom developed or commercial items. Many of these systems are developed by third-party contractors who know very little about the NRC production environments. Currently, development environments are set up completely externally to the NRC, and it is only at the test stage that system integrators encounter problems related to bringing their systems into the production environment.

Therefore, the contractor shall provide a development environment for developers and/or system integrators to work in, which is separated from the production environment. This development environment must simulate the actual production environment so that development issues can be resolved early and real problems can be identified and corrected. Although individual IT system owners must take the responsibility to move their systems through this process, the contractor may be required to assist them in this endeavor.

Requirement – The contractor shall operate the development environment and maintain the ability to develop new applications and hardware to ensure a smooth transition to the test environment

In addition, the contractor shall:

a) Maintain the development environment network including infrastructure, servers, and applications with up to date patching at the same level of the NRC production environment.

b) Ensure that the development environment is segregated from the centralized test and NRC production environments.

c) Operate and manage the development environment to support application development, network performance impact analysis, network modeling and simulation, integration, demonstration, product briefings, evaluation and orientation/training for any software products and custom services and applications to be integrated into the centralized environment.

d) Ensure application and hardware integration into the development environment without adverse impact on the centralized environment.

e) Ensure non-production data sets for development systems can be imported into the development environment. No production data shall be used in the development environment.

f) Provide recommendations for a solution that allows users to develop applications from anywhere by accessing a virtual desktop within the development environment without any risk to the production environment. The NRC reserves the right to decline the recommended solution; therefore, the contractor shall provide this capability upon request and approval in writing by the NRC PO. The recommendation will also need to be approved by the NRC prior to production implementation.

g) Manage a schedule of development environment availability, publish that schedule, and work with customers (to include NRC and other contractors under this acquisition) in scheduling the use of the environment.

h) Ensure availability of the development environment in accordance with the performance metrics defined in Appendix D.

i) Support NRC’s centralized CM personnel in promoting approved system baselines between environments.

j) Minimize the number of incidents associated with any change to the development environment.

k) Provide technical support for the change impact and risk evaluations as part of the NRC CM process.

l) Ensure development environment is kept in synch with the current CM baseline definitions.

m) Use the IBM Rational tools and formal CM processes to manage stable baselines and change requests.

n) Follows the standard CM process to manage the environment infrastructure changes.

C.3.1.6 Test Environment

Objective – The NRC regularly adds and changes technologies. However, as existing IT services are vital to the day-to-day productivity of NRC users, it is essential that the introduction of these changes does not disrupt normal Agency operations. Therefore, all modifications must be thoroughly tested in the NRC’s test environment and appropriate precautions must be taken to mitigate any disruptions that they might introduce.

The contractor shall maintain and operate a Government furnished test environment that simulates the production environment so that tests can be as accurate as possible and real problems can be identified and corrected. Although individual IT system owners must take the responsibility to move their systems through this process, the contractor may be required to assist them to succeed in this endeavor by providing expertise in test environment management and resolving common test environment issues through ensuring that appropriate controls are maintained in the test environment.

The test environment shall operate on a separate network from the production environment. However, personnel in the NRC Infrastructure Computer Operations Division (ICOD) will have the ability to pull code from the NRC centralized test environment for NRC acceptance testing prior to deployment in the NRC production environment.

Requirement – The contractor shall operate the test environment and maintain the ability to test all new applications and hardware to ensure a smooth transition to the production environment.

In addition, the contractor shall:

a) Maintain the test environment network including infrastructure, servers and applications with up-to-date patching at the same level as the production environment.

b) Ensure that the test environment is segregated from the centralized development and NRC production environments.

c) Operate and manage the test environment to support testing, network performance impact analysis, network modeling and simulation, load testing, application testing, testing relating to Section 508 of the Rehabilitation Act of 1973, as amended (see www.section508.gov), integration, demonstration, product briefings, evaluation and orientation/training for all software and custom services and applications to be integrated into the centralized environment.

d) Ensure application and hardware deployed into NRC Consolidated Test Facility (CTF) without adverse impact on the infrastructure.

e) Ensure non-production data sets for testing systems can be imported into the test environment. No production data shall be used in the test environment.

f) Provide recommendations for a solution that allows users to test applications from anywhere by accessing a virtual desktop within the test environment without any risk to the production environment. The NRC reserves the right to decline the recommended solution; therefore, the contractor shall provide this capability upon request and in written approval by the NRC PO. The recommendation will also need to be approved in writing by the NRC PO prior to production implementation.

g) Manage a schedule of test environment availability, publish that schedule, and work with customers (to include NRC and other awardees under this MOM acquisition) in scheduling the use of the environment.

h) Ensure availability of the test environment in accordance with the performance metrics defined in Appendix D.

i) Support NRC’s centralized CM personnel in promoting approved system baselines between environments.

j) Minimize the number of incidents associated with any change to the test environment.

k) Minimize the incidents/problems/errors that are discovered found in the live environment, after system release.

l) Provide technical support for the change impact and risk evaluations as part of the NRC CM process.

m) Ensure test environment is kept in synch with the current CM baseline definitions.

n) Use the IBM Rational tools and formal CM processes to manage stable baselines and change requests.

o) Follows the standard CM process to manage the environment infrastructure changes.

C.3.1.7 Communication

The contractor shall ensure open communication and appropriate information transfer with the NRC PO and other contractors during the period of performance of this acquisition.

C.3.2 FA2: Maintenance and Operations of Legacy Systems

The FA2 contractor(s) shall provide M&O support for the approximately 100 legacy NRC application systems.

Figure 4 provides a high level illustration of how the FA2 contractor(s) will interact with the NRC, as well as, contractors in other functional areas (FA1, FA3, and FA4). The FA2 contractor(s) shall coordinate with the FA1 contractor to develop and test legacy system releases, as directed by NRC change requests. The FA2 contractor(s) shall also provide open communications with FA3 contractor(s) in order to ensure legacy systems are accurately documented during retirements and design efforts. Finally, FA2 contractor(s) shall coordinate with the FA4 contractor(s) during modernization efforts. The FA2 contractor(s) shall ensure that legacy system code is stable and unchanged while modernization efforts are performed. If maintenance is required (and approved in writing by the NRC PO) on a legacy system during modernization efforts, the NRC, FA2 contractor(s), and the FA4 contractor(s) shall work together to ensure any changes to the legacy system are incorporated into the modernized system during the transition period from a legacy system to a modernized system.

Figure 4: MOM M&O of Legacy Systems Overview

As legacy systems are modernized, the requirement for maintenance and operations of legacy systems will diminish.

C.3.2.1 Place of Performance

The anticipated places of performance shall be at the contractor site(s) and/or Government sites in Rockville, MD.

C.3.2.2 Maintenance of Legacy Systems

Objective – Implement changes to the legacy systems as required to deliver minor enhancements.

The key objectives are:

Implement best practices for maintenance activities Facilitate user support during and prior to and during transitional periods when moving users to a new release of the software with an increased improvement during normal operational periods.

Apply cost effective approaches for providing all maintenance activities

Requirements – Key requirements may include, but are not limited to:

a) Providing maintenance support as described in Section C.2.1 above for all identified legacy NRC application systems. The contractor shall ensure perfective maintenance actions are not to be performed while a system is being modernized.

b) Performing configuration management activities as part of all task orders under this acquisition in compliance with Appendix G.

c) Use the IBM Rational tools and formal CM processes to manage stable baselines and change requests.

d) Performing maintenance actions using the current production baseline of the application system which is housed in Rational ClearCase or Rational Team Concert Versioned Object Base (VOBs).

e) Work with FA3 contractor(s) and the FA1 contractor for any Rational tools used and ensure those tools, as directed in writing by the NRC PO, are integrated into the M&O processes.

f) The NRC PO or designee shall notify the contractor of maintenance requests using the Rational ClearQuest or Rational Team Concert CR system and approve the CRs that will be included in each system release using the procedures specified in MD 2.8.

g) Updating all application system changes in the system and security documentation, including any changes that affect the security controls within the application system, prior to system deployment.

h) Coordinate, through the NRC PO, with the NRC Computer Security Office (CSO) and ICOD on changes relating to security controls.

i) Implementing changes to application systems using only the specific products defined in the application system baseline, unless authorization has been received in writing from the NRC PO (i.e., if the application is coded in Java 1.5, only Java 1.5 will be used in the changes).

j) Ensuring that the introduction of any new product to the application system is consistent with the authorized list of products (i.e., the Technical Reference Model (TRM)) or approved by the NRC Environmental Change Control Board (ECCB) prior to implementation.

k) Adhere to existing (or as modified by NRC) Maintenance, Operations, and Modernization Change Request Process as defined in Section C.5.2.

l) Adhere to documentation support requirements. The NRC Configuration Control Board (CCB) will consist of a Parent CCB board and children CCB, which will be subordinate to the Parent CCB. Parent CCB will review documentation requirements in conjunction with segment architecture to determine documentation needs for legacy systems.

m) Ensure all changes requested, while the legacy system is being modernized are formally approved in writing by the NRC CCB prior to system modification.

n) Ensure open communication and appropriate information transfer with the NRC PO and other contractors during the period of performance of this acquisition.

C.3.2.3 Operations of Legacy Systems Objective – The key objective is:

Implement best practices for operational support activities.

Requirement – Key requirements may include, but are not limited to:

a) Using the IBM Rational tools and formal CM processes to manage stable baselines and change requests

b) Developing/Updating a Support Plan to include: how support will be provided, system contact personnel, defect reporting and enhancement request strategy, Performance Metrics, defect prioritization and resolution time periods, defect escalation criteria, how to deliver fixes into production outside the scope of an official release

c) Developing/Updating an Operations Plan to include how a system will be operated and supported in production

d) Modifying data

e) Performing data interpretation

f) Scanning documents

g) Performing Optical Character Recognition (OCR)

h) Entering data

i) Validating data

j) Report generation

k) Producing standard reports

l) Producing ad-hoc reports

m) Providing production support

n) Initiating schedule program sequences

o) Transferring data between systems through kick-off of electronic processes or inputs of tapes or other physical media

p) Performing system monitoring, troubleshooting, and applying immediate corrective measures to agency production application systems (in some cases on a 24-hour, on-call basis)

q) Planning for disaster recovery

r) Developing/updating a plan of actions in the event of disaster

s) Conducting staff training on the disaster recovery plan

t) Conducting periodic testing of the disaster recovery plan

u) Recovering from disaster

v) Developing/updating disaster recovery plan

w) Executing disaster recovery plan

x) Coordinating through the NRC PO with the NRC CSO and ICOD on changes relating to security controls.

C.3.2.4 Enterprise Architecture and Technology Standards

The contractor shall comply with NRC EA requirements and technology standards as outlined in Appendix F.

C.3.2.5 Communication

The contractor shall ensure open communication and appropriate information transfer with the NRC PO and other contractors during the period of performance of this acquisition.

C.3.3 FA3: Requirements and Design

The contractor(s) for FA3 support shall provide NRC with clear requirements definition and high level design recommendations for modernizing NRC’s legacy application systems.

Figure 5 provides a high level illustration of how the FA3 contractor(s) will interact with the NRC, as well as with contractors in other functional areas (FA1, FA2, FA4, and FA5). The NRC will work with the FA3 contractor(s) to identify system requirements. The FA3 contractor(s) shall document requirements within the IBM Rational tools provided by the FA1 contractor in the centralized environment. The FA3 contractor(s) shall also develop the high level functional design recommendations based on the requirements collected. The FA3 contractor(s) shall coordinate with the FA2 contractor(s) to ensure legacy systems are accurately documented during retirements and design efforts. The FA3 contractor(s) shall also ensure open communication with the FA4 contractor(s) to ensure the FA4 contractor(s) understands the requirements and design prior to implementation during modernization efforts. The FA3 contractor(s) shall also coordinate with the FA5 contractor(s) as necessary. The FA5 contractor(s) may identify new requirements and may require an independent analysis from the FA3 contractor(s).

Figure 5: MOM Requirements and Design Overview

FA3 requirements will be divided into application system segments, as described in Section C above.

C.3.3.1 Place of Performance

The anticipated places of performance shall be at the contractor site(s) and/or Government sites in Rockville, MD. Travel requirements will be identified in specific tasks, if required.

C.3.3.2 Requirements Development

Objective – The key objectives are:

The contractor shall produce documentation capturing the business need and translating it into a functional requirements as well as a recommendation for systems infrastructure design.

Requirement – Key requirements may include, but are not limited to:

a) Validate scope provided in task order performance work statement: review and refine the scope as needed and identify any changes to what is in or out of scope once the requirements have been developed. Complete this prior to obtaining the NRC PO sign-off and locking down the scope of the project. Any changes to the requirements after this phase shall be handled through the NRC change control process as defined in MD 2.8 and approved in writing by the NRC PO.

b) Stakeholder Analysis: Perform stakeholder analysis for individual systems to determine stakeholder needs and their relative importance. Use stakeholder input and appropriate methodologies for data collection and analysis, and properly document the process and the findings of the analysis.

i. Identify system stakeholders including all entities that impact or are impacted by the system. Stakeholder identification is to be based on system review by the contractor, and in collaboration with the system owner (appropriate NRC unit). The stakeholder list shall include the system owner, operators, users, and other entities that may be affected positively or negatively by system modification or change. Key stakeholders may include, but are not limited to:

1) Anyone who benefits from the system (functional, political, financial and social beneficiaries)

2) Anyone involved in purchasing or procuring the system.

3) Organizations which regulate aspects of the system (financial, safety, and other regulators)

4) People or organizations opposed to the system

5) Organizations and people responsible for systems which interface with the system under design

6) Organizations who integrate horizontally with the organization for whom the contractor is designing the system

7) Anyone who operates the system (normal and maintenance operators)

ii. Using the stakeholder list, develop appropriate criteria to screen the stakeholders. The stakeholder analysis must be based on actual input (information and quantitative data) provided by all key stakeholders and such input is to be thoroughly analyzed using appropriate methods to identify stakeholder needs and rank their relative importance (e.g., critical requirements, good to have functions and utilities, and functions and utilities that are not needed).

iii. Documented all of the information, data, and methods used in the analysis.

a) Document systems and processes impacted: Create a design-elements diagram for each process function for impact assessment for:

i. People

ii. Process

iii. Technology

iv. Materials and supplies

v. Facilities

vi. Machinery and equipment

vii. Others as necessary (depending on the organization)

b) Document definitions and acronyms: Define any terms not clearly understood by all.

c) Base on requirements, perform alternatives assessment, considering EA requirements in Appendix F and submitting a request to the ECCB to modify the architecture if necessary.

d) The contractor shall provide a target architecture based upon the information gathered above including a detailed process map of the target architecture. When distinguishing impacts group the process functions into the following categories:

i. People: People are processing information and making decisions [core team designs high-level design/low-level design (HLD/LLD)]

ii. Systems: Systems is processing information and making decisions

iii. Systems/People Dependencies and Action Points: System is processing information and people are making the decisions

iv. Fishbone: For each process function for impact assessment

v. Requirements and design will cover all nonfunctional items. Examples:

1) Identify the intended user

2) Identify the number and type of users

3) Identify the level of computer experience users will have (or will need)

4) Identify architecture constraints and requirements

5) Identify hardware and network constraints – networked or stand-alone

6) Identify statutory and regulatory requirements, to include, but not limited to:

i. Section 508 of the Rehabilitation Act of 1973, as amended

ii. Federal Information Systems Management Act (FISMA) security controls

iii. National Archives and Record Administration

iv. Privacy Act

7) Identify the approximate data and performance requirements and anticipated growth

8) Determine change management requirements

9) Identify technical support needs and in-house availability

10) Identify what other systems are needed to integrate/communicate

11) Determine backup and disaster recovery requirements

12) Define expected deliverables (e.g. – system requirements and design documentation)

13) Determine which requirements are mandatory versus optional

e) Use the IBM Rational tools and formal CM processes to document requirements.

f) Coordinate through the NRC PO with the NRC CSO and ICOD on changes relating to security controls.

C.3.3.3 High Level Design or System Design

High Level Design (HLD) gives the overall System Design, in terms of functional architecture, user interface definitions, process flows, as well as database design. This is very useful for the developers to understand the flow of the system. In this phase, the design team, testers, and end users play a major role. The entry criteria shall be the functional requirements document and the exit criteria shall be HLD recommendations, the functional design documents, and the database design document.

Objective – The key objectives are:

High level software design, also called software functional architecture, is the first step to analyze and consider all requirements and attempt to define a system that will support implementation. The non-functional requirements have to be considered, such as scalability, portability and maintainability. This first design step has to be mostly independent of a programming language and infrastructure.

Requirement – HLD – Based on business requirements, business process analysts will convert the requirements into a usable product. This design depicts the business process flow and decision points. In the design process, the product is to be broken into independent functional modules.

a) The HLD functional design document will at a minimum contain the following items at a macro level:

i. A list of functional modules and a brief description of each module

ii. A brief description of functionality of each module and what data or calculations are required

iii. A definition of any interface relationship among functional modules

iv. Any dependencies between functional modules

v. Any know data sources identified along with key elements

vi. An overall functional architecture diagram along with any known technology details.

b) Coordinate through the NRC PO with the NRC CSO and ICOD on changes relating to security controls.

C.3.3.4 Use Cases, Test Plans, and Test Cases, The contractor shall develop use cases, test plans and test cases based on the requirements and design efforts. The contractor shall use the IBM Rational tools to document use cases, test plans and test cases. The contractor shall update any and all associated documents any time changes are made during the contractor’s period of performance.

C.3.3.5 Communication

The contractor shall ensure open communication and appropriate information transfer with the NRC PO and other contractors during the period of performance of this acquisition.

C.3.4 FA4: Modernization of Legacy Systems

This functional area will allow the NRC to modernize legacy application systems.

Figure 6 provides a high level illustration of how the FA4 contractor(s) will interact with the NRC, as well as, contractors in other functional areas (FA1, FA2, FA3, and FA5). The FA4 contractor(s) shall modernize the legacy application system based on the requirements and high level functional design provided by the NRC. The FA4 contractor(s) shall work within the centralized environment provided by the FA1 contractor. The FA4 contractor(s) shall ensure open communication with the FA3 contractor(s) to ensure a smooth transition of the requirements and high level functional design into the modernization effort. If a modification to the legacy system is absolutely necessary during modernization efforts, then the FA4 contractor(s) and the FA2 contractor(s) shall work together to ensure continued service to NRC end users. Finally, the FA4 contractor shall ensure a smooth transition of the modernized system to the FA5 contractor(s) for maintenance and operations (M&O) support.

Figure 6: MOM Legacy Modernization and New Development Overview

FA4 requirements and deliverables will be dependent on FA3 requirements.

C.3.4.1 Place of Performance

The anticipated places of performance shall be at the contractor site(s) and/or Government sites in Rockville, MD.

C.3.4.2 Modernization

Objective – Implement changes to the legacy systems as required to deliver enhancements base on delivered requirements and HLD identified by the FA3 contractor(s).

During the detailed phase the HLD is broken down into modules and programs. Logic design is done for every program and then documented as program specifications. For every program a unit test plan shall be created.

The entry criteria for FA4 will be the Requirements and HLD document. The exit criteria shall be the modernized system, including the program specification and unit test plan comprising the Low Level Design (LLD).

The HLD contains details at macro level and so it cannot be given to programmers as a document for coding. The system analysts shall prepare a micro level design LLD document. This document shall describe each module in an elaborate technical manner, so that the programmer can directly code the program based upon the functional design. The LLD will at a minimum contain:

a) A detailed programmatic functional logic of the module, in pseudo code

b) All database tables, with all elements, including their type and size

c) All interface details with complete Application Programming Interface (API) references (with a visual diagram and supporting text)

d) All dependencies and constraints

e) All error responses, recovery and error message listings

f) Complete list of inputs and outputs for each module

Key objectives are:

a) Create a more homogeneous NRC IT environment (see architecture requirements and preferred technologies in Appendix F) by modernizing applications to use similar platforms, programming languages, and databases

b) Implement best practices for modernization support activities

c) Maintain compliance with applicable industry standards, as specified in task order performance work statement

d) Apply cost effective approaches for providing all modernization activities

Requirement – Key requirements may include, but are not limited to:

a) Ensuring the robustness, integrity, quality, consistency and/or performance of the NRC application systems

b) Providing a detailed segment portfolio modernization plan

c) Modernization activities shall include one or more of the following approaches:

i. Improving the robustness, integrity, quality, consistency, and/or performance of a system

ii. Converting an application from one technology set to another (e.g. from PowerBuilder to .Net or Java)

iii. Moving a system from one computer platform to another computer platform (e.g. from Windows to Linux platform)

iv. Combining two or more systems into one.

d) Adhere to Maintenance, Operations and Modernization Change Request Process, as described in Section C.5.2

e) Adhere to documentation support requirements

f) Screen mock-ups

g) Usability testing

h) Coordinate, through the NRC PO, with the NRC CSO and ICOD on changes relating to security controls

C.3.4.3 Communication

The contractor shall ensure open communication and appropriate information transfer with the NRC PO and other contractors during the period of performance of this acquisition.

C.3.5 F5: Maintenance and Operations of Modernized Systems

The contractor(s) selected to provide M&O of Modernized Systems shall provide maintenance and operational support for identified NRC application systems.

Figure 7 provides a high level illustration of how the FA5 contractor(s) will interact with the NRC, as well as, contractors in other functional areas (FA1, FA3, and FA4). The FA5 contractor(s) shall coordinate with the FA1 contractor to develop and test minor enhancement and maintenance system releases, as directed by NRC change requests. The FA5 contractor shall also ensure a smooth transition of modernized systems from the FA4 contractor(s) to ensure continued M&O support. The FA5 contractor(s) shall also ensure open communication with the FA3 contractor(s) if independent requirements analysis and design is required by the NRC.

Figure 7: MOM M&O of Modernized Systems Overview

Maintenance and Operations of Modernization Systems will be divided into segments, as described in Section C above, and will be dependent on the associated FA4 contract(s).

C.3.5.1 Place of Performance

The anticipated places of performance shall be at the contractor site(s) and/or Government sites in Rockville, MD.

C.3.5.2 Maintenance of Modernized Systems

Objective – Implement changes to modernized systems as required to deliver minor enhancements and fixes.

The key objectives are:

a) Implement best practices for maintenance activities.

b) Facilitate user support during and after transitional periods when moving users to a new release of the software with an increased improvement during normal operational periods.

c) Apply cost effective approaches for providing all maintenance activities

Requirements – Key requirements may include, but are not limited to:

a) Providing maintenance support as described in Section C.4.2 above for identified modernized NRC application systems.

b) Performing configuration management activities as part of all task orders under this acquisition in compliance with Appendix G.

c) Use the IBM Rational tools and formal CM processes to manage stable baselines and changes requests.

d)…