Waterfall Methodology: Technology Solution Analysis and Design Process

PURPOSE ▪ SCOPE ▪ PROCESS DESCRIPTION ▪ PROCESS DIAGRAM ▪ PROCESS INPUTS/OUTPUTS ▪ PROCESS RELATIONSHIPS ▪ ROLES AND RESPONSIBILITIES ▪ SUPPORTING DOCUMENTATION ▪ REVISION HISTORY

Process Owner: Manager, Solutions Development and Support

Note: An owner must be a PCES-level manager or higher.

This process establishes standard tools and processes for the TSLC Waterfall Analysis and Design phase within the Postal Service Technical Environment.

1. PURPOSE

The Technology Solution Analysis & Design process translates the Technology Solution Requirements into an implementable design and finalizes the project’s implementation schedule and costs. Technology components are identified and architected to provide a framework in support of the Technology Solution Build phase.

The objectives of the Analysis & Design process are:

2. SCOPE

The Technology Solution Analysis & Design process applies to all technology solution projects including, but not limited to, one or more of the following:

3. PROCESS DESCRIPTION

The Technology Solution Analysis & Design process creates a documented design from approved technology solution requirements.

This process is composed of the following sub-processes:

1. Perform Risk Assessment

Application risk assessment is an ongoing process designed to minimize risk to applications by identifying additional security controls (beyond those initially established) to be deployed that are commensurate with the relative values of the assets to be protected, the vulnerabilities associated with those assets, and threats to the application. Non-sensitive technology solutions may use the Abbreviated Risk Assessment.

This process includes the following steps:

Step 1: Identify possible threats that could adversely affect the business solution.
Step 2: Identify security vulnerabilities that could be exploited by threat events affecting the business solution.
Step 3: Analyze implemented and planned controls against requirements.
Step 4: Identify the probability that a vulnerability may be exploited.
Step 5: Identify the adverse impact resulting from a successful exploitation of vulnerability.
Step 6: Identify possible additional mitigating controls that, if applied, could be expected to mitigate the risks identified for the business solution.
Step 7: Document the overall risk status of the business solution.

2. Develop Technology Solution Design Documents

Host designs, database designs, network designs, application designs, etc., are developed as appropriate based on the approved requirements document. Host designs may use the provided TSLC template. All technology solution designs will encompass those environments (such as Development, Test, CAT, Prod, and Training) that have been defined within the scope of the technology solution requirements.

3. Develop Technology Solution Security Control Plan

Technology Solution Security specifications are documented to satisfy the security requirements defined by the Business Impact Assessment (BIA). The TSPM analyzes the security requirements and specifications established for the application and identifies potential security controls in light of business requirements, Postal Service policies, and cost versus benefit of the various control options. Security controls for the technology solution are selected by the project team to satisfy the privacy and security requirements identified through conducting the BIA and to mitigate the risks identified in the technology solution risk assessment or abbreviated technology solution risk assessment. Multiple information security controls may be needed to satisfy a particular information security requirement, or one control may satisfy more than one information security requirement.

This process includes the following steps:

Step 1: Documenting the security specifications.
Step 2: Identifying security controls and processes for baseline, mandatory, and selected discretionary security requirements defined during the Risk Assessment.
Step 3: Selecting security controls on their ability to meet security requirements and provide a cost-effective security solution.

4. Design Walkthrough with All Appropriate Technology Service Providers

All Technology Service Providers who have a stake in the technology solution will bring their draft designs to a walkthrough session. The designs will be reviewed against the requirements, and approval must be obtained by the Enterprise Architecture Committee for all projects introducing new or expanded use of IT services, technology solutions, or COTS software. This review process also applies to projects that require upgrades to software previously approved for inclusion in the IT Tool Kit (ITK). The objective of the walkthrough is for all IT Service Providers to agree on the design. Any changes to requirements as a result of the design must go through the CCB. 

5. Submit SOX System Impact Assessment (SIA) Form to SOX CCB (SOX Systems Only)

SOX Systems are required to complete the SOX SIA and submit it to the SOX Change Control Board (SCCB) when implementing changes to the system functionality (add/remove/enhance) or the system architecture. The SCCB will perform an analysis of a requested change against the SOX Controls defined for the requesting application and provide list of required remediation actions or approval. This is a Baseline requirement for all SOX in-scope systems that must be stored in the TSLC Artifacts Library.

6. Create Draft System Integration Test (SIT) Strategy

The Draft SIT Strategy is developed early and is an output of the Technology Solution Analysis & Design process to support generation of accurate and committed cost and schedule. The Draft SIT Strategy will include the following information:

7. Create Draft CAT Strategy

A Customer Acceptance Test (CAT) phase is needed to ensure that the technology solution satisfies the key system requirements for the business customer. The Draft CAT Strategy is developed early to support the generation of accurate cost and schedule. The Draft CAT Strategy will include the following information:

8. Determine Components to Be Procured

This process involves performing preliminary procurement activities, such as a “making versus buying” analysis and procurement / award supplier identification (award will not occur until after the TSLC design process). This information will be utilized in the development of the project cost and schedule.

9. Develop CAT Scripts

The CAT scripts are documented test scenarios that outline input data, sequence of test steps, and expected output values. The CAT scripts define the technology solution acceptance criteria. Once the test scenarios have been developed, the CAT team will walk through all scenarios to ensure that requirements are thoroughly tested. This is a Baseline requirement, for all SOX in-scope and out-of-scope systems, that must be stored in the TSLC Artifacts Library.

10. Assemble Cost and Schedule from Technology Service Providers

At this point the requirements are signed off and placed in change control in the Requirements phase. The Technology Solution Coordinator (BPL with IBSSC developed solutions) has up to two weeks to request, obtain, and compile the technology solution implementation costs and schedule milestones from the Technology Service Providers. DARs and large project technology solution implementations that will require longer than the two week timeframe may request an extension in writing in advance from the Portfolio Manager responsible for the technology solution. Though the technology solution costs and schedule milestones have been provided, the Technology Solution Coordinator continues to complete and obtain signoff on the technology solution design document.

11. Updated Project Plan

The project plan is updated with the information from the milestone information from the Technology Solution Providers. At this point the project plan has all the tasks to commit and implement the technology solution.

12. Present Costs and Schedule

The total project implementation costs and schedule are presented to the customer for a decision to proceed with the building process or continue with the technology solution Analysis and Design process in the event this has not been completed.

13. Technology Solution Implementation Cost and Schedule Customer Approval

Upon the customer review of the cost and schedule to develop the Technology Solution, a decision is made in writing by the customer to proceed with the Build process (or design if not completed). If approved to proceed, funding is obtained to support the rest of the TSLC processes in implementing the Technology Solution.

14. Implement Design Document Change Control

Upon formal approval of the design document by the appropriate Technology Solution Providers, the technology solution design document is placed under change control. Any changes to the design document must go through the CCB process.

4. PROCESS DIAGRAM

In this section, there is a process diagram of the Technology Solution Analysis and Design process. The Process steps are stacked vertically in the center; as each process step is completed, there is a downward arrow to the next process step in the sequence. On the left side are Inputs which inform the process step in the center from which there is an Output. For some process steps, there may not be an input and/or an output. The first process step is to Perform a Risk Assessment for which the inputs are the Approved Technology Solution Requirements, the Traceability Test Matrix and the Business Impact Assessment. The Approved Technology Solution Requirements artifact has an asterisk to indicate that it is a Baseline Requirement. The output of this process step is the Risk Assessment. The second process step is to Develop the Design Document; this process step does not have a corresponding input, but its output is the Technology Solution Design. The third process step is to Develop the Security Control Plan; this process step does not have a corresponding input, but its output is the Technology Solution Security Control Plan. The fourth process step is to Design the Walkthrough; this process step does not have a corresponding input, but its outputs are the Approved Technology Solution Design and the second EA Checkpoint approval. The fifth process step is to Submit the SOX System Impact Assessment; this process step does not have a corresponding input, but its output is the SOX System Impact Assessment Form (if applicable). The SOX System Impact Assessment Form has an asterisk to indicate that it is a Baseline Requirement. The sixth process step is Create the Draft SIT Strategy; this process step does not have a corresponding input, but its output is the Draft SIT Strategy. The seventh process step is Create the Draft CAT Strategy; this process step does not have a corresponding input, but its output is the Draft CAT Strategy. The eighth process step is to Develop the CAT Scripts; this process step does not have a corresponding input, but its output is the CAT Scripts. The CAT Scripts has an asterisk to indicate that it is a Baseline Requirement. The ninth process step is to Determine Components to be Procured; this process step does not have a corresponding input or output. The tenth process step is to Assemble Costs and Schedule; this process step does not have a corresponding input, but its output is the Technology Solution Implementation Costs. The eleventh process step is to Develop the Final Project Plan; this process step does not have a corresponding input, but its output is the Project Plan Final Baseline. The twelfth process step is to Present the Cost and Schedule; this process step does not have a corresponding input or output. The thirteenth process step is to get Customer Approval; this process step does not have a corresponding input, but its outputs are the Technology Solution Funding and Schedule Approval, and the Updated Traceability Test Matrix. The fourteenth process step is Change Management; this process step does not have a corresponding input or output. There are no further process steps for this process.

An asterisk (*) denotes a Baseline requirement.

5. PROCESS INPUTS/OUTPUTS

Inputs

Outputs

An asterisk (*) denotes a Baseline requirement.

6. PROCESS RELATIONSHIPS

In this section, there is a relationship diagram of the Technology Solution Analysis and Design process. There are eight processes which comprise the USPS Technology Solution Lifecycle (TSLC) Technology Solution Planning methodology. The processes are aligned vertically as bookends next to each other, specifically: the first process is Initiate and Plan; the second process is Technology Solution Requirements; the third process is Analysis and Design; the fourth process is Technology Solution Build; the fifth process is System Integration Testing (SIT); the sixth process is Customer Acceptance Testing (CAT); the seventh process is Governance Compliance; and the eighth process is Release Management. For all of the processes, there are both Inputs and Outputs to the planning activity. Within the Technology Solution Analysis and Design process, the inputs for the analysis and design activity are the Technology Solution Requirement with Approval, the Traceability Test Matrix, and the Business Impact Assessment. The Technology Solution Requirements with Approval artifact has an asterisk to indicate that it is a Baseline Requirement. The Approved Technology Solution Requirements artifact has an asterisk to indicate that it is a Baseline Requirement. Within the Technology Solution Analysis and Design process, there are several outputs. Outputs from the Analysis and Design process are the Risk Assessment, Technology Solution Design, Security Control Plan, and the Enterprise Architecture Checkpoint 2 approval. Outputs to the Technology Solution Build process are the Updated Project Plan, the Technology Solution Implementation Cost, Technology Solution Design with Approval, the Updated Traceability Test Matrix, and the TS Funding and Schedule Approval. Outputs to the System Integration Testing (SIT) process are the Technology Solution Design with Approval and the SIT Strategy. Outputs to the Customer Acceptance Testing (CAT) process are the Technology Solution Design with Approval, the CAT Strategy and CAT Scripts. The CAT Scripts artifact has an asterisk to indicate that it is a Baseline Requirement. The output to the Governance Compliance process is the SOX System Impact Assessment Form (required for SOX projects only). The SOX System Impact Assessment Form has an asterisk to indicate that it is a Baseline Requirement. There are no additional outputs of the Technology Solution Analysis and Design process.

An asterisk (*) denotes a Baseline requirement.

7. ROLES AND RESPONSIBILITIES

8. SUPPORTING DOCUMENTATION

For access to the following documents, contact the US Postal Service. See Publication 5, Let's Do Business for further information about local US Postal Service contacts.

9. REVISION HISTORY

Version #1.0  
Section(s) Revised: N/A
Revision Description: Baseline
Revision Date:  
   
Version #1.1  
Section(s) Revised: Process Diagrams
Revision Description: Add Web browsers alternative Analysis and Design process diagram text.
Revision Date: 03/23/2010
   
Version #1.2  
Section(s) Revised: Process Relationships
Revision Description: Add Web browsers alternative Analysis and Design process relationship text.
Revision Date: 03/23/2010
   
Version #1.3  
Section(s) Revised: Title
Revision Description: Added “Waterfall”
Section(s) Revised: Introduction
Revision Description: Updated Process Owner to: Manager, Solutions Development and Support to reflect current organization
Section(s) Revised: 4 – Process Description, 5 – Process Diagram, 6 – Process Inputs/Outputs, 7 – Process Relationships
Revision Description: Added CAT Scripts (moved from CAT phase)
Section(s) Revised: 4 – Process Description; 9 – Roles and Responsibilities
Revision Description: Updated SOX PMO to SOX CCB; removed references to SOX freeze
Section(s) Revised: 4 – Process Description, 5 – Process Diagram, 7 – Process Relationships
Revision Description: Added indicators and text for baseline artifacts
Section(s) Revised: 5 – Process Diagram
Revision Description: Final Project Plan and Technology Solution Implementation Cost are outputs to a later TSLC phase instead of an earlier TSLC phase.
Section(s) Revised: 5 – Process Diagram, 7 – Process Relationships
Revision Description: Added text in non-displayable format for Section 508 compliance
Revision Date: 02/22/2012
   
Version #1.4  
Section(s) Revised: All
Revision Description: This document was made Section 508 compliant and was converted to HTML.
Revision Date: FY12/Q3