6_Amend0004.doc

SECTION SF 30 BLOCK 14 CONTINUATION PAGE

SUMMARY OF CHANGES

SECTION SF 30 - BLOCK 14 CONTINUATION PAGE

The following have been added by full text:

CONTINUATION PAGE

The purpose of Amendment 0004 is to update the Request for Proposal (RFP) as a result of questions received on the RFP. The following changes are made:

1. Section C, Paragraph 4.9, Inspection and Acceptance Criteria has been modified to update all references to deliverable delivery within 5 working days to 10 working days.

2. Section J has been modified to incorporate Attachment 11, Average Annual Volume of Request Types Historical Data.

3. Section L has been updated to allow for examples of CDRL deliverables to be provided in a page-unlimited appendix which would not count against the Volume 2, 50 page limit.

4. Section M has been updated as follows:

a. Paragraph M-3 c (3) (f) has been updated to reflect the contract reporting clearly meets the Contract Deliverable Table specified in the PWS, paragraph 1.6.2.

b. Paragraph M-3 c (3) (f) has been updated to clarify that examples are only required for any CDRL deliverable to be submitted in an alternate format other than what is specified in the PWS.

5. Attachment 8, Cost Template has been updated as follows:

a. The data deliverable worksheet has been removed in its entirety.

b. The labor summary tab has been modified to list the three (3) “Key” categories as reflected in Section H-4, Key Personnel and the PWS.

c. An additional labor summary tab has been added. One labor summary tab will be used for FFP labor and the other tab for cost reimbursable labor.

d. The cost template has been updated to remove WBS element, Task Management.

e. The ODC tab has been removed.

f. The travel, hardware and software tabs have been simplified.

SECTION C - DESCRIPTIONS AND SPECIFICATIONS

The following have been modified:

PERFORMANCE WORK STATEMENT

Performance Work Statement for

Agile Transportation for the 21st Century (AT21)

Business Process Transformation for the

United States Transportation Command (USTRANSCOM)

March 13, 2007

1.0 DESCRIPTION OF SERVICES

1.1 SCOPE

1.1.1 The scope of this effort will be to identify and implement business processes and systems that enable the DOD’s distribution planning, transportation planning, and transportation execution activities in support of the Joint Deployment Distribution Enterprise (JDDE) business enterprise. This effort will apply best business practices and leverage order management and transportation management technologies within a three-phased incremental acquisition.

The effort will focus less on capturing the “as-is” processes and more on providing a solution “blueprint” that best meets the program objectives (mission capability and performance), addressing and integrating the myriad enterprise-wide elements including: organization, culture, personnel competency, business processes, facilities and assets, and enabling information technology. The ultimate solution shall define and enable end-to-end integrated processes to achieve transformational impact, rather than applying technology to existing processes for incremental improvement.

1.1.2 This requirement will be managed in increments as shown below. Initiation of each increment is not necessarily dependent on the completion of the previous increment. However, the Government requires funding and Milestone B approval prior to initiating Increments 2 and 3.

The Capability Development Document (CDD) defines the performance-based functional and technical requirements for this effort. In the event of any inconsistency or ambiguity, the CDD takes precedence over the PWS.

1.2 BACKGROUND

USTRANSCOM, in partnership with the Defense Information Systems Agency (DISA), conducted an AT21 Advanced Concept Technology Demonstration (ACTD) from 2003 – 2005. During Oct - Nov 2004, USTRANSCOM and the United States Central Command (USCENTCOM) conducted a military utility assessment (MUA) of the ACTD’s transportation planning system, in order to assess the operational and cost benefits of its concepts and capabilities. The eight-day exercise consisted of parallel transportation-planning operations for USCENTCOM’s deployment and redeployment transportation requirements using the ACTD’s system and the incumbent processes and systems.

The AT21 ACTD defined primary functional areas for process control, collaboration, optimization, and visualization. Supporting controlled processes with appropriate information technologies is seen as vital in enabling USTRANSCOM to achieve effective integrated transportation management within the larger DOD supply chain. The AT21 ACTD demonstrated commercial off the shelf (COTS) supply chain execution (SCE) and supply chain management (SCM) technologies as a cost effective way to provide capabilities supporting the transformation of operations that would deliver more effectively to the war fighter.

Independent assessment of the MUA exercise revealed the following measured benefits of AT21 when compared to the incumbent system.

1. Significant improvements in planned on-time delivery by air and sea.

2. Significant improvements in load consolidation and more effective use of airlift and sealift in the conveyance of cargo and passengers.

These benefits can be explained by the following observations regarding the AT21 ACTD system.

1. The ACTD system demonstrated that it can generate transportation plans significantly quicker than the incumbent system, enabling system users to implement those plans sooner and respond to planning changes sooner and thereby respond to Joint Force Commander requirements for forces and sustainment more effectively and efficiently.

2. The automated processing within the ACTD allowed action officers to focus their efforts on exception management rather than routine processing thus allowing action officers to be more productive.

3. Increased staff efficiency requiring an expected 30% less effort will free action officer time for more detailed analysis of requirements and plans and for other tasks.

1.3 OBJECTIVES

The primary goal of the AT21 initiative is the attainment of a business process transformation resulting in a modern enterprise business system that enables USTRANSCOM to achieve the following objectives:

1. Reengineering of USTRANSCOM distribution planning, transportation planning, and transportation execution processes through implementation of appropriate “best business practices” resulting in more timely and efficient delivery of forces and sustainment.

2. Enhanced supply chain capabilities resulting in precise, more reliable deployment and distribution delivery, increased customer satisfaction via tailored distribution support, and reduced customer wait time.

3. Achievement of an environment that enables item visibility throughout the supply chain and leads to decreased materiel costs.

The goal is to focus the distribution and transportation planning segments of the supply chain by reengineering business processes to bring into the USTRANSCOM environment best business practices that integrate robust, commercial-off-the-shelf (COTS) or Government-off-the-shelf (GOTS) software. It is the USTRANSCOM’s intent to leverage robust existing COTS/GOTS product suites in lieu of designing, developing, and maintaining a unique system. USTRANSCOM’s desire to incorporate available technology is not only to reduce acquisition and operating costs, but more importantly to embrace both continuous business process improvement and technology insertion provided by robust enterprise-level software suites. USTRANSCOM desires technology currently in use by leaders within industry or Government that enables cutting edge business practices and that has a proven track record as technologically superior in scalability and configuration. These objectives represent USTRANSCOM’s approach to meeting the requirements of the DOD Logistics Strategic Plan and the JDDE. AT21 will contribute to improved military readiness by implementing a more interoperable, integrated data environment and resolving the Joint Logistics (Distribution) Joint Integrating Concept [JL(D) JIC] imperative shortfalls: conduct JDDE assessment and planning, control JDDE operations, and conduct JDDE performance analysis.

1.4 BUSINESS MODEL

The USTRANSCOM vision is an enterprise business system supporting its role as the DoD’s Distribution Process Owner as well as executive decision-making and rapid, cross-organization process automation and information sharing. It is critical to recognize that the USTRANSCOM business model is changing from the current environment of autonomous business units to a new Joint environment consisting of a collaborative, integrated deployment and distribution enterprise. This includes common business processes and data across transportation planning and execution activities. Additionally, the new business model will migrate the command toward a common enterprise business system and more reliance on detailed collaborative relationships with supported Combatant Commanders (COCOMs), the Defense Logistics Agency (DLA), the Services, the Transportation Component Commands (TCCs), and other national and industry partners.

1.4.1 USTRANSCOM BUSINESS STRATEGY

USTRANSCOM requires an enterprise business system that will inter-operate with existing and future COCOM, DLA, Service, and TCC systems to achieve these goals. The capability of an expanded supply chain, which reaches from the organic DPO capability, into the private sector, and out to our customers, will provide the DPO that visibility and access to global deployment and distribution information that it does not have today, improving the quality and velocity with which USTRANSCOM provides deployment distribution delivery services and information to its customers. Business process re-engineering and continuous improvement in USTRANSCOM business practices is a primary objective to ensure that USTRANSCOM can (1) Move the Joint Force; (2) Sustain the Joint Force; and (3) Operate the Joint Distribution and Deployment Enterprise.

To answer increasing demands on the DPO to support force projection and sustainment, AT21 is focused on identifying and applying best business processes and practices and supporting COTS/GOTS software tools to improve the planning and managing of DPO distribution and deployment assets in support of the COCOMs. As the DPO continues to transform into a lead logistics provider, the AT21 business enterprise umbrella will bring the information from the execution elements (organic and commercial carriers) together and make the information readily available to our customers. The DPO will combine process, technology and best practices to manage the DOD distribution enterprise.

The USTRANSCOM Focus Warfighter I (FW I) initiative took place during spring 2005 when TCJ3 reorganized – involving COCOM-oriented branches and the redesign of the requirements validation process. This effort proved successful from both the COCOM and USTRANSCOM perspectives and resulted in better Warfighter support. The follow-on FW II concept transformation realigns planning functions while realigning current processes to meet specific COCOM support requirements. FW II provides the baseline for Information Technology (IT) development to increase effectiveness in delivering combat power to the Warfighter while enhancing visibility and efficiency of the distribution process. The concept permits USTRANSCOM to tailor its Deployment & Distribution Operations Center (DDOC) operations to respond to world events with the appropriate level of effort required—by standing-up COCOM-specific divisions in a Joint Operations Center. FW II transitions USTRANSCOM from the strategic planning/monitoring function to a more heavily focused end-to-end transportation planning and concept of operations (CONOPS) development and event management development roles. FW III focuses on transportation planning and customer relationship management (CRM). The objective is to optimize controlled distribution processes by employing advanced, globally networked tools and techniques.

AT21 will directly support the JL (D) JIC imperatives and resolve Joint Deployment and Distribution Enterprise (JDDE) capability gaps. The Focus Warfighter initiative, as the process change driver for AT21, rests on three pillars: Process improvement; Organization; and Information Technology. AT21 is just a portion of the larger USTRANSCOM effort to improve end-to-end (E2E) distribution for the Department of Defense (DOD).

USTRANSCOM Strategic Guidance 2007: The Strategic Plan’s goals, outcomes, and objectives are developed to support the Commander, USTRANSCOM’s Command Guidance and the JL (D) JIC to provide the best distribution possible to the Warfighter distribution enterprise and sharing of distribution information with all USTRANSCOM’s national and industry partners.

The strategy to develop an environment based on collaboration to synchronize all distribution events across DOD is enabled by the JDDE. The JDDE provides the framework for a global distribution capability that supports adaptive planning and agile execution for the Joint Force Commander (JFC).

The backbone of the JDDE is the collaboration of the enterprise partners that enables delivery of joint capabilities either within the theater of operations or from the point of origin directly to the point of effect.

The Focus Warfighter II realignment charter is to develop a process that capitalizes on a joint fused effort to assess and plan multi-modal end-to-end solutions. This process will synchronize the distribution of forces and sustainment into the theater through collaborative planning, proactive transportation analysis, performance monitoring, increasing distribution effectiveness and customer confidence. COCOM-oriented branches in the Fusion Center will process all COCOM end-to-end requirements and provide a natural link into the respective theater Joint DDOC (JDDOC). In addition to providing improved support to COCOMs, USTRANSCOM must also effectively and efficiently manage the large volume of routine (sustainment) unit and freight movement within CONUS and to non-combat OCONUS areas including support to high–volume users such as AAFES, DeCA, and GSA.

AT21 embodies the USTRANSCOM Strategic Guidance Hierarchy:

1. Mature the Joint Deployment and Distribution Enterprise (JDDE)

a. Create JDDA

b. Simplify processes

c. Improve forecasting and planning

d. Improve JDDE performance and reduce system variation by 30%

e. Improved analysis

1. Requirements data capture and requirements management work flow to facilitate visibility over all movement requirements, multi-modal analysis and asset management decision-making, correlating complete, constrained (and unconstrained) movement requirements with planning rationale, permitting deployment planners to visualize and analyze movement requirements and employ scheduling decision information (with respect to modal assets, weather, particular routing information, and infrastructure data)

AT21 shares responsibility for improvements in the following areas:

a. Improved Customer Wait Time (CWT) for sustainment

b. Reduce Required Delivery Date (RDD) and/or Projected Closure Date (PCD)/Commit Date variation

c. Reduce Integrated Distribution Lane (IDL) process variation

d. Integrated RFID/Related AIT CONOPS

2. Leverage Collaboration and Partnerships

a. Transform workflow

b. Streamline distribution portfolio

2. Generate information into a configurable collaborative environment that displays improved C2 situational awareness/decision-ready movement tracking information

3. Develop Expeditionary Approaches

a. Shape expeditionary tools for better COCOM support

b. Adapt business models

c. Implement Joint Theater Logistics

3. Materiel solutions in the form of process improvements enabled by COTS automated tools hold significant promise as keys to substantial improvement in responding to the deployment and sustainment demands of the Warfighter and the increased operational tempo of expeditionary forces.

4. Enable Joint Distribution Concepts

a. Responsive mobility systems

b. Appropriate mix lift assets/all domains

4. Information broker for constrained distribution/deployment requirements through a seamless CRM-like customer/user web-enabled interface, generating the single view to the customer for workflow status and exception management and requirements tracking as close as possible to the consuming theater unit, identifying each dynamic distribution/ deployment requirement through the workflow and feedback/ reporting processes

The goal of this procurement is to deploy an approach that incorporates business process reengineering, change management, and COTS supply chain management and execution tools to meet the strategic goals listed above.

USTRANSCOM intends to enhance the performance of business system interoperability in response to the increasingly complex business environment and changing customer needs. To achieve this, USTRANSCOM may find it necessary to realign and perform process and system improvements.

1.4.2 TEAM INTEGRATION

Effective implementation for an enterprise business system will require cooperation and knowledge sharing among the Contractor, USTRANSCOM Integrated Product Teams (IPTs), and DPO functional and technical organizations. USTRANSCOM and the Contractor will jointly identify the desired USTRANSCOM operational participation required and time frames needed to support its implementation approach. Throughout the period of contract performance, USTRANSCOM will reserve the right to periodically review the level of USTRANSCOM resources identified and associated time frames in an effort to continually employ the appropriate and required resources.

The program manager will be guided by an Executive Steering Group chaired by the USTRANSCOM Chief of Staff that meets quarterly or as required, and involves customers and stakeholders from not only USTRANSCOM, but also its TCCs, COCOMs, DLA, other agencies as appropriate, and the Contractor. The USTRANSCOM Chief of Staff serves as the program’s Milestone Decision Authority and Program Executive Officer. Permanent members of the Executive Steering Group include the USTRANSCOM Director of Operations and Plans (the program’s functional sponsor); the Director of Strategy, Policy, Programs, and Logistics; and the Director of Command, Control, Communications & Computer Systems.

During solution development, change management tasks should support the executive sponsors, including the development and coordination of program expectations; reinforcing program objectives; creating and distributing program-level communications; marketing the program, and tracking, reporting, and acting on feedback from stakeholders.

1.5 TASKS

The Contractor shall perform the following tasks for each increment. Post Increment 3 activity shall be limited to the efforts identified in paragraph 1.5.3.

1.5.1 PROJECT MANAGEMENT

The Contractor shall manage the cost, schedule, and performance of the effort and identify key personnel assigned to the project. The Contractor shall implement standard, repeatable processes for managing and executing the program. The Contractor shall deliver to the Government an independent appraisal of process maturity assessed at Software Engineering Institute (SEI) Capability Maturity Model® Integration (CMMI), or similar process standard, for the entire AT21 development team at the beginning of each increment. The Contractor shall obtain Government approval prior to obtaining a process maturity assessment if the appraisal is measured against a standard other than CMMI, The Contractor’s project manager shall be available for face-to-face meetings with the PMO and staff, as required, to ensure common understanding of all ongoing activities. Additionally, the Contractor shall perform the following tasks and provide the following deliverables. The Contractor may propose alternative reports and formats as substitutes for any of the deliverables required in this section and describe the impact each substitution will have on cost, schedule and performance of this contract. The Government will evaluate the proposed alternatives to determine if they meet the intent of the requirement and may select some, all or none as appropriate substitutes.

1.5.1.1 Task Management. The Contractor shall prepare an Integrated Master Plan (IMP), an event-based plan consisting of a hierarchy of program events, with each event being supported by specific accomplishments, and each accomplishment associated with specific criteria to be satisfied for its completion. The IMP will also describe the technical approach, organization resources, and management controls required to meet cost, performance, and schedule requirements throughout contract execution. The Contractor shall provide a monthly status report describing program cost, schedule, and performance for the period along with updates to program risk, quality assurance, configuration management, and security management. The monthly status report shall be traceable to the Integrated Master Schedule (IMS), defined in section 1.5.1.4 and the CPR, defined in section 1.5.1.5., and includes a graphical depiction of the resources used for the current period and fiscal year to date with a delta below. The report shall list the deliverables for each task and any issues, problem areas, or items that require Government review. The AT21 Technical IPT will review the development Contractor’s IMP and, if necessary, the Government’s chief systems engineer may recommend changes to the IMP through the AT21 COR to ensure the technical development activities are adequately documented. The IMP shall contain the following in contractor format:

1) Events – logical points to assess the program’s progress;

2) Significant Accomplishments – Two* or more for each event, defining the desired results prior to or at completion of each event;

3) Criteria – Two* or more for each significant accomplishment defined as measurable information that provides definitive evidence that a specific accomplishment is being completed. Completion of all of these criteria constitutes completion of the accomplishment; and

4) Narratives (if required to further the understanding of the IMP) – Narratives may be categorized as two types: Process Narratives and Task Narratives.

a) Each narrative should be limited to 05 pages and include Statement of Objectives—what is the purpose of the process or task being addressed and how will it be tailored or implemented for this program.

b) The Offeror shall provide Task Narratives to describe the approach to execute those tasks for which there may be no specific IMP accomplishments (e.g., level-of-effort tasks such as configuration management or program control).

* There may be instances where one is acceptable

1.5.1.2 Contract Work Breakdown Structure. The Contractor shall develop a contract work breakdown structure (CWBS) (Data Item Description (DID) number DI-MGMT-81334A), to provide a framework for program and technical planning, scheduling, cost estimating, resource allocations, contract performance measurements, and status reporting. The CWBS shall define the total application to be developed or produced; display the total process as a product-oriented family tree composed of business process re-engineering, change execution, process control, hardware, software, services, data, and facilities; and relate the elements of work to each other and to the end product. The Contractor shall provide a corresponding CWBS Dictionary that provides a definition of all CWBS components to include cost elements. Guidance for the CWBS can be found in MIL-HDBK-881. The Contractor shall deliver the initial CWBS for Government review and approval. Over time, the Contractor shall adjust the CWBS as needed based on Government direction.

1.5.1.3 Technical Interchange Meetings. The Contractor shall conduct Technical Interchange Meetings (TIMs) at various locations to document the requirements and schedule. The Contractor shall provide an agenda for each TIM at least 2 work days prior to a scheduled TIM. Formal minutes shall be drafted by the Contractor and delivered to the AT21 Contracting Officer Representative (COR) within 5 work days after each TIM. The Contractor shall work with the AT21 program management team to arrange TIMs as required throughout the contract life.

1.5.1.4 Integrated Master Schedule. The Contractor shall deliver a resource-loaded Integrated Master Schedule (IMS) (DID number DI-MGMT-81650) in Microsoft Project 2003, or higher, based on the CWBS described in paragraph 1.5.1.2. The IMS shall identify the project critical path and schedule risk shall be analyzed based on the project critical path. Once delivered, the Government approval is required prior to changing the IMS. The Contractor shall deliver recommended changes to the IMS monthly.

1.5.1.5 Earned Value Management. The Contractor shall implement Earned Value Management in accordance with the American National Standards Institute/Electronic Industries Alliance Standard 748 (ANSI/EIA-748). The Contractor shall host a Government Integrated Baseline Review (IBR) to verify EVM compliance. Once the Contractor’s EVM system is verified, the Contractor shall deliver a Cost Performance Report (CPR) (DID number DI-MGMT-81466A) monthly. Metrics are to include schedule efficiency, budget efficiency, and overall project efficiency. The Contractor shall deliver a Contract Funds Status Report (CFSR) monthly in a Contractor proposed format, subject to Government approval. In addition to the EVM proposal, the Contractor may propose metrics that the Government can use in place of EVM, including examples of successful implementation on previous projects.

1.5.1.6 Risk Management. The Contractor shall implement a process to identify, analyze, manage and mitigate risk. The Contractor shall develop a Risk Management Plan documenting this process. The Contractor shall identify risk updates in a Risk Report, which shall be delivered monthly.

1.5.1.7 In-Process Reviews. The Contractor shall present In-Process Reviews (IPRs) monthly, or at the AT21 Program Manager’s request. The IPR presentations shall use the IMP and IMS to describe project performance, cost and schedule status; progress; concerns; and recommendations for project software, process implementation, change management, program risks, and other issues impacting AT21. The Contractor shall deliver a copy of the presentation slides not later than (NLT) 3 work days prior to the IPR and minutes NLT 5 work days after the IPR. At a minimum, the minutes shall reflect a record of meeting activity, decisions made, action items, date, location, and attendees.

1.5.1.8 Configuration Management. The Contractor shall develop a configuration management process, with associated automated tools for control of requirements, releases, source code and documents. The Contractor shall document these procedures in a configuration management plan for delivery to the Government. The Government will provide comments within 10 work days. Once any issues are resolved, the Contractor shall incorporate comments within 10 work days. A Configuration Control Board (CCB) structure, which includes the PM, Contractor, and DOP IPT co-chairs, will be used to prioritize requirements for each spiral.

1.5.1.9 Market Research. The contactor shall conduct ongoing market research to identify the latest industry best practices and software tools for distribution and transportation management. The Contractor shall document recommended baseline process and IT changes to the Program Manager through Engineering Change Proposals (ECPs) (DI-CMAN-80639C).

1.5.1.10 Other Data. The Contractor shall make available to the Government any data produced as a normal course of managing the AT21 program. The Contractor shall identify the data in a data accession list and provide this data as requested by the Government. All contractor work products delivered under this contract become the property of the U.S. government.

1.5.1.11 Collaboration. The Government encourages but does not require that the Contractor establish a collaborative web site. Components of a web site would be;

a. Posting of approved documents,

b. Document review and approval collaboration site

c. IPT sub-sites

d. Private program management site with dash board and, potentially, direct feeds from the Contractor management system

1.5.2 DESIGN, DEVELOPMENT, AND DEPLOYMENT

1.5.2.1 Business Process Improvement

1.5.2.1.1 Business Processes. The Contractor shall review documentation, conduct interviews, meetings, and working sessions to facilitate a common understanding of current business processes and business rules (for both data and business processes). The Contractor shall conduct business process reengineering and recommend best business practices for streamlining existing business processes and implementing “to be” business processes. Resulting business processes and rules are to be stored in a retrievable and reusable fashion. The Contractor shall propose the delivery schedule for the associated deliverables.

1.5.2.1.2 Blueprinting. The Contractor shall develop an end-to-end solution blueprint that details the recommended strategy and prioritization for implementing business process improvements, adopting best practices, and implementing supporting technology.

1.5.2.1.3 Change Management. The Contractor and the Government shall jointly develop a change management plan for incorporating business process improvements and automated tools into the DOD joint planning culture and business environment. The Contractor shall support the Government’s change execution throughout the life of the AT21 program. The Contractor shall document ongoing activities in a Change Management Tracking Report. The Contractor shall propose the delivery schedule for these deliverables.

1.5.2.2 Systems Engineering

1.5.2.2.1 Architecture Design. The Contractor shall develop and deliver an end-to-end architecture design in close collaboration with the Government. The design will be at a level of detail sufficient to ensure integrated capability for Increments 1-3. Contractor shall propose the delivery schedule for this deliverable. The development Contractor may use results from the AT21 ACTD in their own development effort. The design must include recommendations for business process reengineering, procurement of hardware platforms, middleware, and application software needed for each increment. The Contractor design shall maximize business process reengineering and minimize software customization and the use of reports, interfaces, conversions and extension (RICE) objects. The Contractor design shall conform to DOD Architecture Framework (DoDAF) requirements and format. The Contractor design shall leverage and/or interoperate with the evolving USTRANSCOM Enterprise services and toolsets described in the following table:

1.5.2.2.2 Spiral Capability Design

AT21 development will follow a spiral development methodology. Spiral development is a cyclical approach for incrementally growing capabilities. A spiral encompasses a complete definition, implementation, and deployment cycle bounded by schedule, funding, or business constraints. Using process blueprinting and business rules, the Contractor shall incrementally develop the detailed design required to configure each specific software capability spiral. The software capability spirals need to correspond (in content and timing) to business processes changes identified and scheduled via Business Process Reengineering (BPR) and change management. The government expectation is that the Contractor solution will maximize the use of COTS software and require minimal system changes with maximum emphasis on USTRANSCOM BPR.

There are four phases to the development process: the Requirements Phase, Functional Phase, Design Phase, and Test/Implementation Phase, each of which is described below.

1.5.2.2.2.1 Requirements Phase

The purpose of the Requirements Phase is to manage AT21 preliminary design requirements and to identify inconsistencies between those requirements and the IPT plans and work products. The requirements phase is comprised of those activities necessary to ensure Government insight into the contractor’s requirement decomposition process and to ensure the Contractor has a clear understanding of the desired capability.

Through discussions with the program manager and functional users, the Contractor shall perform Requirements Management as the initial set of activities within each spiral development cycle. Requirements Management has four distinct goals:

a. Requirements engineering to provide a current approved set of prioritized, refined requirements

b. Requirements tracking to manage changes to the requirements over the life of the program.

c. Requirements traceability to decompose and allocate requirements and maintain bi-directional traceability of requirements

d. Requirements verification to show compliance and identify inconsistencies between requirements and work products The Contractor shall enter their findings into a consolidated requirements document and a requirements traceability matrix. The Contractor shall present the draft consolidated requirements document and a requirements traceability matrix to the AT21 COR for approval in a System Requirements Review (SRR). The functional community must have an opportunity to review the consolidated requirements at the SRR before approval to proceed is given. The consolidated requirements document and associated Requirements Traceability Matrix (RTM) become the requirements design baseline and subject to the configuration management directives mandated by the AT21 COR.

1.5.2.2.2.2 Functional Phase

The AT21 engineering activities revolve around the definition and evolution of the system architecture. An architecture centric process is an approach to developing systems where the development activities are closely coupled to the definition and resulting usage of the architecture in creating, integrating, reusing and validating the system, hardware and software products. Employing explicit models of the system being developed is an essential characteristic of an architecture centric process.

Particular areas of focus for the AT21 architecture include:

a. Identification and understanding of key interfaces, interoperability, and domain/cross domain threads

b. Representation of workflow and user’s intent

c. Identification and analysis of bottlenecks and resource utilization

d. Creation of a general, reusable service oriented architecture model

e. Laying out the logical database interactions and schema

f. Understanding the impact and applicability of Commercial-Off-the-Shelf (COTS) and Government-Off-the-Shelf (GOTS)

g. Planning the reusable components and web services

The Functional Phase details how each system component performs to meet the functional and technical requirements of the solution. During this phase, the integration contractor develops a Functional Specification that captures the fundamental elements or processes and the data flow between these processes, and describes how the system architectural components are used to meet the operational requirements, with specific reference to the applicable Key Performance Parameters (KPPs) and attributes identified in the CDD. This phase represents the bridge between the Requirements and the Design phases. The Functional Specification forms the framework of how the technical components of the architecture will be choreographed to satisfy the desired capabilities. The Functional Phase provides the government the ability to have insight and Governance to promote reuse prior to the detailed design.

The desired outcome of this phase is a completed Functional Specification, an updated Test Specification, an updated Training Plan, an updated schedule, a Logical Data Model (LDM), an updated RTM, and an updated Deployment Plan. By the end of the Functional Phase, the integration contactor shall be able to determine how the requirements will be met, the tool set to be used, the data sources, the logical data model, the reports from a functional perspective, and the logical source to target mapping.

At the end of the Functional Phase, the contractor shall conduct a Functional Specification Review with the Government. Once the review is successfully completed, the contractor shall enter the Design Phase. The Government will validate that all artifacts for this phase are complete and available for the review.

1.5.2.2.2.3 Design Phase

The primary goal of the Design/Construction Phase is to develop the detailed design of each component being built to address the customer’s requirements. Then the contractor transforms those design specifications into software artifacts. These components could be system extensions, as in the case of a purchased package solution; or they could be custom components to be used with a package, or as a total solution. The contractor shall design components to ensure reutilization of services, Extract, Transform, and Load (ETL) processes, and Business Intelligence (BI) solutions to the maximum extent possible.

The component interfaces are designed in accordance with established and maintained business rules captured in the Logical Data Model. This effort develops a complete data package for the product, product component, or capability. Interfaces are thoroughly documented and maintained once the capability is fielded. The design is captured in a Design Specification, Interface Requirements Design Document (IRDD) for each source system, an updated Test Specification, an updated Training Plan, an updated RTM, an updated LDM, the Physical Data Model (PDM), and an updated Deployment Plan. These deliverables shall provide the required information on how the solution will be developed, how it will be tested as well as the detailed mapping from customer requirements to functional capabilities. The Contractor shall conduct a Critical Design Review with the Government to reach agreement on the design approach.

As part of the Design Phase, the Contractor will transform the approved detailed design specification into software artifacts and start unit testing. The code and unit test process incorporates the following concepts:

a. Creation of developmental and/or modified software code

b. Traceability between software requirements, design, and code

c. Effective use of the project’s corrective action system

d. Effective use of the project’s change control process Unit test metrics are captured and maintained by the Contractor based on unit test outcomes such as number of defects, effort expended to fix defects, and elapsed time from defect detection to closure. Peer code reviews, and unit testing provide the primary means of detecting defects in the code and unit test process and products Problem Reports (PR) document defects.

At the conclusion of this phase, the Government, in coordination with the Contractor, will validate that the developed system meets the requirements baseline and that all artifacts for this phase are complete and available for review.

1.5.2.2.2.4 Test/Implementation Phase

The Test/Implementation Phase implements the solution based upon the Design Specification and IRDDs. This phase includes both testing and deployment. The Test Specification documents how each component will be tested upon initial implementation. The desired outcome of this phase is a completed testing cycle and the successful implementation of the spiral.

The Contractor shall independently verify, validate, and test that the integrated system meets the detailed requirements by executing the detailed test plans in the Test Specification. The Test Specification shall define and guide the overall testing strategy. It shall define the test activities from unit through operational test along with the testing schedule and roles/responsibilities. The testing shall be conducted for each specific requirement and shall validate and verify that the products, user interface, Problem Reports, change requests, and specific test cases are properly tested/retested. Tests which receive less than a “pass” rating shall be documented as a Problem Report and resolved to the Government’s satisfaction before testing will be considered complete and before the specific activity can be released to the production environment. A Test Analysis Report (TAR) will be created that documents the results of contractor testing.

Testing consists of the following processes:

a. Plan the Process: Refine and elaborate the plan for performing all tests. Organize the work and assign responsibilities. Define methods for measuring progress. Allocate resources and schedules and ensure that the resources (for example, tools, staff, training) are, or will be, available when required.

b. Track and Oversee the Process: Monitor the program’s progress against the plan. Ensure that the project’s defined software process is followed. Update the plan or process as needed to account for actual performance in accordance with project procedures. Coordinate and conduct technical interchange meetings and formal and informal customer and project reviews. Ensure that action items and problem/change reports are tracked to closure. Ensure that all products meet technical and project requirements. Ensure that peer reviews are conducted in accordance with plans. Ensure that resources are available when required.

c. Conduct Spiral Integration Test: Refine test articles (baseline software, data definitions, databases, files, data, and procedures) and Spiral Integration Test procedures. Perform the preliminary Spiral/Increment Integration Test in accordance with the Spiral Integration Test Plan. At the end of each Spiral, there is a system integration test. This test validates the individual product capabilities are interoperable and perform together as field capable. Tests will normally be conducted on the Integration Test Node at the Contractor’s facility, depending on complexity and test requirements. To the maximum extent possible, Integration testing will address development test and operational test objectives to reduce total test requirements. Government witnessing and participation is encouraged.

d. Perform Re-Test and Regression Tests: Update software Spiral Integration Test cases and procedures as required in accordance with configuration control procedures. Turn over test procedures and any new test environment items for configuration control. Since each Spiral is built on the foundation established in the proceeding Spiral, it is critical that newly developed capabilities do not degrade/impact existing capabilities. As part of the Integration Testing process, selected regression tests will be performed in each Spiral to validate that previous capabilities operate properly.

e. Stress Testing: Ability to meet system stress requirement is validated through test and analysis.

At the conclusion of the contractor testing, a Test Readiness Review (TRR) shall be held to verify the system is ready for Government testing. This effort will validate that the requirement and functional specifications allocated to this Spiral have been achieved. A successful TRR indicates that the software artifacts are ready to be loaded onto the Test Suite. CM will validate that all artifacts are complete and available for this review.

Government Testing. Government testing requires successful completion of the TRR and acceptance of the Test Analysis Report (TAR). The Government testing reviews will verify that all functional and performance requirements allocated for each spiral and tested by the Contractor during development testing will meet the Requirement and Functional Specifications, with emphasis on the applicable Key Performance Parameters (KPPs) and attributes identified in the CDD. Installation instructions and configuration items are testable areas for inclusion into formal testing. During this phase the contractor will assist the Government both at the contractor and Government facilities as necessary to include:

a. Support facility preparation

b. Support system hardware and/or software upgrades

c. Support execution of the installation instructions

d. Government test execution

Security Testing. The DoD Information Assurance Certification and Accreditation Process (DIACAP) is integral to the development efforts and security testing occurs at each Spiral. Security testing will occur on the pre-production test node. Independent testing may also be conducted at each Spiral if the Government requires. This Incremental approach mitigates the risk of not meeting security requirements and ensures the timely granting of the Authority to Operate/Certificate to Operate before operational testing. The Government security engineer will observe the security testing. During the DIACAP accreditation process, the AT21 system will be subjected to an independent Security Test and Evaluation (ST&E). The AT21 ST&E will validate the correct implementation of identification and authentication, audit capabilities, access controls, object reuse, trusted recovery, and network connection rule compliance. Individual tests evaluate system conformance with the requirements, mission environment, and architecture. Security test plans and procedures developed by the independent test organization will address security requirements and provide sufficient evidence of the amount of residual risk. Security testing, compliance verification, system management analysis, site accreditation survey, contingency plan evaluation, and a risk management review are conducted during ST&E. The results of the test will be reviewed and added to the AT21 System Security documentation by the contractor as specified in 1.5.2.2.3.7 Technical Documentation. Each of the tests, validations, and reviews will produce a record of findings, evaluation of any vulnerabilities discovered, a summary of the level of effort used, a list of the tools used, and results. Additionally, recommendations for corrections can be included with the results of the validation activities.

1.5.2.2.3 Systems Engineering Processes

The systems engineering processes outlined in the subparagraphs below shall be used:

1.5.2.2.3.1 Reference Data Management

The Contractor shall use enterprise reference data sources to provide a capability that maintains the current state of the transportation network infrastructure required to support distribution planning and execution process activities.

1.5.2.2.3.2 Verification and Validation

Verification and validation will occur via formal testing. Verification and validation of the AT21 system will be conducted as outlined in the Test & Evaluation Master Plan (TEMP). All formal testing will occur either at the Contractor test facility or in the Government facility in which hardware and software are to be installed for operational use. The Contractor will conduct in-house testing before technical reviews, milestone reviews, and delivery of any spiral. Feedback from test and evaluation efforts is part of the systems engineering process and shall be incorporated into the AT21 system design as appropriate.

The TEMP is the responsibility of the Government, with input from the development Contractor. The TEMP includes testing the AT21 IT tool suite, testing the interfaces and testing between AT21 and other AISs. The Government will coordinate this part of testing with the PMs of the other systems.

The Government’s chief systems engineer will conduct a Test Readiness Review (TRR) to approve the test plans used and results produced by the development Contractor during Contractor testing before the Government commences full, formal Operational Test & Evaluation (OT&E).

1.5.2.2.3.3 Reviews

AT21 program technical and functional reviews shall be held monthly for the first three months, then quarterly, or as recommended by the chief systems engineer and the functional IPT chairman. For the first three months, reviews shall be held monthly. Where possible, these reviews will be performed in conjunction with the IPRs identified in paragraph 1.5.1.7. These reviews include an overview of development progress, identification of risks, identification of challenging issues, and other topics of interest as determined by the Government or Contractor. All reviews will also contain updates of measures as discussed in the Measures section of this document. The deliverable at these reviews is a presentation and, if warranted, a demonstration of processes and system components. The Contractor shall provide presentation materials and record minutes documenting each technical review.

The SRR, CDR, Functional Specification, and TRR reviews ensure that AT21 program development is progressing as planned. The AT21 COR has final approval for exiting each design review.

Preproduction Readiness Review (PRR). The Contractor shall accomplish a PRR prior to bringing users into the testing phase. The PRR will validate that the system is ready for user testing. Functional validation of the Spiral will be necessary prior to deployment.

User Acceptance Tests (UAT). The Contractor shall perform UATs, which require successful completion of the PRR. Each Spiral establishes the performance baseline and expectations for that Spiral.