II.H MSWP 3.0 SOW Appendix A.pdf

Appendix A

This appendix provides examples of configuration change requests and associated work unit(s) to set a baseline understanding of what the government considers the scope of a single work unit that will be tasked via configuration change requests on this contract. Some configuration change requests may contain several work units. Three configuration change request examples have been provided that represent what the Government considers a single work unit. One configuration change request example has been provided that the Government considers to be 5 work units. It is noted, these configuration change requests are for scope understanding purposes only and are not provided for execution. Configuration Change Requests for execution will be provided to the contractor following contract kickoff.

The Government used the following as an outline for determining the number of work units in each of the following work requests. Each of the following items was determined to represent a single work unit:

• Required BMIDE changes to accomplish a configuration change request

• Required Workflow changes to accomplish a configuration change request

• Required Report changes to accomplish a configuration change request

• Required Interface changes to accomplish a configuration change request

• Required system configuration work that does not fit into one of the categories above which is required to accomplish a configuration change request

Configuration Change Request Example 1 (Scope is equal to one work unit):

Background:

This configuration change request is to address open M&SWP Teamcenter AutoScheduler defect “OA Defect NR. 814 - UNSAT Autoscheduler when capacity Avail Type changed from RFT to ERO”. The capacity limit is ignoring the availability type. Some availabilities have capacity limits, where particular jobs, in the form of RCOs, fill the capacity of a particular availability. When the capacity limit is hit, RCOs who ‘should’ be scheduled in the availability are scheduled earlier into an appropriate availability with a ‘Scheduled Early’ indicator. Currently, when the capacity limit and Availability Type is revised such that additional RCO(s) can fit into an availability, AutoScheduler is not scheduling the RCOs into the availability it should, ignoring the availability type. The Government can demonstrate this issue upon request.

Work Requested:

1. Evaluate and provide the root cause of why AutoScheduler is ignoring availability types for RCOs with capacity limits when the avail type is changed from RFT to ERO.

2. Determine and present corrective actions for Government concurrence.

3. After receiving Government concurrence, modify, deploy, and test the changes to AutoScheduler.

The Government can provide additional information on the AutoScheduler process and capacity limits as needed.

Configuration Change Request Example 2 (Scope is equal to one work unit):

Background:

This Configuration Change Request is to address the open M&SWP 3.0 Defect “NR. 542 System is not capturing digital signatures for workflow approvals”. During the third User Acceptance Testing (UA 3) it was discovered that when completing a workflow step that required gathering approval, the user who performed the “approval” action is recorded but the digital signature is not captured nor is there a prompt by the system to capture the cert or pin. The Government can demonstrate this issue upon request.

Work Requested:

1. Evaluate and provide root cause for why M&SWP 3.0 workflow approval actions are requesting the approval but are not prompting for a cert selection or pin input.

2. Determine and present corrective action for government concurrence prior to execution of corrective action.

3. Following Government concurrence, implement and test corrective actions necessary for the M&SWP 3.0 workflow approval cert and pin prompt.

The government can provide additional details on digital signatures as defined in FIPS-140-2 as well as the services provided by the digital signature and how it impacts business.

Configuration Change Request Example 3 (Scope is equal to one work unit):

Background:

This configuration change request is to address open TcRA Defect “OA Defect NR. 807 – Main Shaft Report Wrong Avails Highlighted Gray.” During operational assessment, it was discovered that the Main Shaft Replacement Schedule Report is not always highlighting the correct Availabilities in Gray. The report should be highlighting the Availability where the next occurrence of an open Maintenance Action (MA) or forecasted Requirement Component Object (RCO) is scheduled with a scheduling indicator that will be counted as a completion. The Government can demonstrate this issue upon request.

Work Requested:

1. Evaluate and provide root cause for why the Main Shaft Report is not always highlighting the Availability gray where the next occurrence of an open MA or Forecasted RCO is scheduled with a scheduling indicator that will be counted as a completion.

2. Determine and present corrective actions to the Government for concurrence.

3. Upon receiving Government concurrence, implement and test changes to the Main Shaft Report such that the report is highlighting the correct availabilities gray.

The Government can provide additional details on the Main Shaft Report, including business need, upon request.

Configuration Change Request Example 3 (Scope is equal to five work units):

Background:

This work request is to address Job Control Number Bundling, commonly referred to as JCN Bundling or Bundling. In M&SWP 2.0, bundling works by putting together a collection of (usually) similar jobs, called Scheduled Maintenance Requirements (SMRs) under one Master Job File Control Number (MJFCN).

Within this group of jobs, one of the jobs is marked the “parent”. When the bundle is called down, all of the SMRs get the same JCN and that parent JCN represents the entire bundle in the work package. When the group of jobs are completed, the parent is marked as complete, and all of the jobs within the bundle “get credit” and are marked as complete as well, followed by AutoScheduler updating their LMA dates in the system.

Bundling is an exclusive feature to Ohio and Columbia Class Submarines (726 and 826 Class respectively).

Currently, bundling is a feature in M&SWP 2.0 that does not exist in M&SWP 3.0. Ohio Class repair facilities (IMF Bangor and TRF Kings Bay) have indicated that maintaining the ability to bundle is essential to their business function. In order to satisfy their need, M&WP 3.0 will need to be modified to allow for bundling.

Bundling Requirements for M&SWP 3.0:

Bundling in M&SWP 3.0 must be similar in nature to bundling in M&SWP 2.0, such that:

a. A bundle consists of a group of user selected Requirement Component Objects (RCOs).

o RCOs in a bundle will originate from the same platform.

o Bundled groups of RCOs may be unique to a hull; there is no implied task to manage bundles at the class level, nor replicate bundles through the CDMD-OA interface. Each bundle is managed independently of each other.

o A single RCO may exist in multiple bundles.

b. The RCO must have a text attribute field for “MJFCN”. (Limited to 13 Characters consisting of both Numbers and Letters) o Currently, the MJFCN field exists at the MR level, and should not – MJFCN is RCO specific.

c. The neutral and physical availability object must have a new, user set attribute (yes/no check-block) that indicates bundling enabled/disabled for the availability.

o The system workflow “MSWP Create Platform Schedule” must provide functionality for physical availabilities to inherit the attribute from the neutral schedule.

d. The solution must provide the means for a user to review a bundle of RCOs from a single screen/window, and add/remove RCOs from the bundle as necessary.

e. The solution must provide the means for the user to place a bundle of RCOs into an availability, and provide a unique scheduling indicator, as outline in [f.] below.

f. The Auto Scheduler must adhere to the following requirements:

o Auto Scheduler will determine if the bundling enabled attribute from [c.] has been toggled.

If yes, Auto Scheduler will determine if the parent of the bundle is in/should be in the availability.

If the parent of the bundle is in/is placed into the availability, ALL children of the bundle are also placed into the availability, and given a scheduling indicator of “J”.

• If the RCO is already in the availability as a child of ANOTHER bundle, it is given a scheduling indicator of “j”.

A child of a bundle may be the parent of another bundle or relationship; all relationship rules and bundling rules apply to the children of the child.

o The parent of the bundle must get its “Actual” scheduling indicator

g. When a Work Package is created, Maintenance Actions (MAs) must be created for the bundle at that specific availability.

o These MAs must have identical JCNs within each bundle o The MJFCN must be visible and populated at the MA level o All bundled MAs must appear within the package, grouped together, and be easily distinguished as part of a bundle.

o The solution must provide the means for a user to review a bundle of MAs, and add/remove MAs from the bundle.

o Multiple bundles must be able to coexist within a work package.

h. When the bundle is marked complete, all of the bundled jobs at the MA level, must automatically be marked complete as well.

o Bundled MAs must be editable as well, such that it is possible to “roll-back” individual jobs within the bundle that were not actually completed.

i. A bundle must be able to be broken at the RCO and MA level such that individual jobs can be called to a work package without the rest of the bundle.

o The solution needs to be designed with the end user in mind, who may need to frequently call individual jobs into an availability.

o The system must be able to individually track and manage RCOs/MAs, their scheduled availabilities, work packages, and completions, which bundles they are a part of, and which availabilities and work packages the bundles are apart of.

j. CDMD-OA must alert users when an RCO that is a part of a Bundle is deactivated, or re-activated.

o If a conventional RCO-to-RCO relationship is used in the solution design, Specification 1.5.2, REQ-152-126.1 “All rco-to-rco relationship creation functionality [must be] assumed by Teamcenter [runtime]” is waived for bundled relationships, per requirement [a.], bullet 2 of this work request.

k. The MMF outgoing interface must be changed to incorporate the MJFCN shift from the MR object to RCO Object.

l. The auto scheduler interface must be adjusted to account for the solution design, as well as account for the new scheduling indicators (See [f.] above). Scope of change is largely dependent on solution proposed.

m. Any impacts to any other interfaces, such as the MM0001, must be clearly identified to the Government team prior to implementation.

n. Bundles must not utilize the “Supersede” functionality, as is, that is currently built into the system.

o UROs must maintain visibility when bundled.

o. Users must be able to search for bundles at the RCO and MA level utilizing the MJFCN field.

Work Requested:

1. Evaluate options for incorporating Bundling into M&SWP 3.0 following the requirements as identified above.

2. Determine and present potential solutions for Bundling in M&SWP 3.0 to the Government team for concurrence. The proposed potential solutions should incorporate at least the following:

a. Follow the requirements as outlined above

b. A detailed explanation on how the proposed Bundling solution would function

c. Potential risks associated with the Bundling solution

d. Detail on any custom coding or “Out of the Box” solutions, if applicable

3. Following Government concurrence, implement and test the Bundling solution.

The Government team is able to provide additional details on Bundling upon request.