SLM Work Patterns.pdf

Version 2.2 April 2008

Pre-defined Work Patterns

Immigration and Customs Enforcement System Lifecycle Management

Pre-defined Work Patterns

REVISION HISTORY

ICE SLM Pre-defined Work Patterns April 2008

Version Date Summary of Changes

2.0 April 2006 Reorganized sections

Added Scrum work pattern (Section 3.0) Added Legacy System work pattern (Section 6.0) Added External Service work pattern (Section 7.0)

2.1

January 2008 Brought into alignment with SLM 1.1 Global: Milestone Review changed to Technical Review Global: Office of the Information Systems Security Manager (OISSM) changed to Information Assurance Division (IAD) Director Global: System Owner changed to Business Owner Global: Application Integration Services changed to Application

Hosting Services Global: OISS changed to IAD Global: IAD (formerly OISS) Document Artifacts added to : Document

Artifacts Exhibits: 2, 6, 9, 12, 15, 18, 21 Global: AHS changed to SEB Global: Notice of Intent to Release is required for all Releases Global: Procurement Plan changed to Acquisition Plan Global: formatting in tables simplified and made consistent CH 1.0, page 1:

-IT Project Managers changed to Architecture Assurance -Added: to paragraph 2: Depending on the type of project, Architecture Assurance may use one of these pre-defined work patterns for a project:

-Added to paragraph 3: SLM technical reviews, and types of testing

-Aligned document artifacts list in each section to current Project Tailoring Plan and SLM v1.1 Exhibit 2: Additional comments added to Acquisition (formerly, Procurement) Plan and ITCR, Data conversion Plan, Training Plan Development Test Plan, DTAR, VDD, System Administration and Operations Manual, User Guide, Disposition Plan

Exhibit 5: improved graphic for visual differentiation Exhibit 7: Additional comments added to Acquisition Plan, ITCR, Training Plan, Development Test Plan, DTAR, VDD, System Administration and Operations Manual, Deployment Plan, Disposition Plan

Exhibit 8: Scrum Gate Reviews updated Exhibit 9: Scrum Testing Types Rationale updated Exhibit 11: COTS/GOTS Document Artifacts, updated Acquisition

Plan, Data Conversion Plan, Exhibit 12: Revised comments for Planning Review, PADR, FADR Exhibit 13: COTS/GOTS Testing Types updated Interoperability, Performance, Section 508 Exhibit 15: Infrastructure Document Artifacts, updated Acquisition

Plan Exhibit 15: Infrastructure Gate Reviews, updated Planning Review, TRR, RRR

Exhibit 17: Infrastructure Testing Types, updated System Security, Interoperability, Section 508

6.0 Desktop Image, new chapter, new exhibits as follows:

Exhibit 18: Desktop image Project Examples

Exhibit 19: Desktop Image Document Artifacts Exhibit 20: Desktop Image Gate Reviews Exhibit 21: Desktop Image Testing Types Exhibit 23: Legacy System Document Artifacts, updated Acquisition

Plan, NIR Exhibit 24: Legacy System Gate Reviews, revised Planning Review Exhibit 25: Legacy System Testing Types, revised Interoperability, Performance, Section 508 External Services changed to External Service Exhibit 27: External Service Document Artifacts, updated Acquisition

Plan, System Administration and Operations Manual, User Guide Exhibit 28: External Service Gate Reviews, updated Planning Review Exhibit 29: External Service Testing Types, updated Interoperability, Section 508 Exhibit 31: Simple Content-Based Web Site Document Artifacts, updated PMP, IAD artifacts Exhibit 32: Simple Content-Based Web Site Gate Reviews, updated

Planning Review Exhibit 33: Simple Content-Based Web Site Testing Types, updated

System Acceptance, Interoperability, Section 508 Chapter 6: Desktop Image: new chapter added Testing Types exhibit added to all sections Pr-defined Work Patterns version updated to 2.1 Brought in line with SLM 1.2 planning Chapter 10 Mainframe: new chapter added Chapter 11 SharePoint: new chapter added

2.2 April 2008 Chapter 8 External Service removed

7.3, Exhibit 23: added DTAR 9.2, Exhibit 30: added DTAR

CONTENTS i

CONTENTS

1.0 OVERVIEW

2.0 FAST TRACK

2.1 Fast Track Project Profile

2.2 Fast Track Document Artifacts

2.3 Fast Track Gate Reviews

2.4 Fast Track Testing Types

3.0 SCRUM

3.1 Scrum Sprints

3.2 Scrum Considerations

3.3 Scrum Project Profile

3.4 Scrum Document Artifacts

3.5 Scrum Gate Reviews

3.6 Scrum Testing Types

4.0 COTS/GOTS

4.1 COTS/GOTS Project Profile

4.2 COTS/GOTS Document Artifacts

4.3 COTS/GOTS Gate Reviews

4.4 COTS/GOTS Testing Types

5.0 INFRASTRUCTURE

5.1 Infrastructure Project Profile

5.2 Infrastructure Document Artifacts

5.3 Infrastructure Gate Reviews

5.4 Infrastructure Testing Types

6.0 DESKTOP IMAGE

6.1 Desktop Image Project Profile

6.2 Desktop Image Document Artifacts

6.3 Desktop Image Gate Reviews

6.4 Desktop Image Testing Types

7.0 LEGACY SYSTEM (NON- MAINFRAME)

7.1 Legacy System Considerations

7.2 Legacy System Project Profile

7.3 Legacy System Document Artifacts

7.4 Legacy System Gate Reviews

7.5 Legacy System Testing Types

8.0 SIMPLE CONTENT-BASED WEB SITE

8.1 Simple Content-Based Web Site Project Profile

8.2 Simple Content-Based Web Site Document Artifacts

8.3 Simple Content-Based Web Site Gate Reviews

8.4 Simple Content-Based Web Site Testing Types

i i CONTENTS

April 2008 ICE SLM Pre-defined Work Patterns

9.0 MAINFRAME

9.1 Mainframe System Considerations

9.2 Mainframe System Document Artifacts

9.3 Mainframe Gate Reviews

9.4 Mainframe Testing Types

10.0 SHAREPOINT

10.1 SharePoint Document Artifacts

10.2 SharePoint Gate Reviews

10.3 SharePoint Testing Types

APPENDIX A—REFERENCES

CONTENTS ii i

EXHIBITS

Exhibit 1: Fast Track Project Example Exhibit 2: Fast Track Document Artifacts Exhibit 3: Fast Track Gate Reviews Exhibit 4: Fast Track Testing Types Exhibit 5: Scrum Requirements, Architecture, and Design Maturation... 10 Exhibit 6: Scrum Project Example Exhibit 7: Scrum Document Artifacts Exhibit 8: Scrum Gate Reviews Exhibit 9: Scrum Testing Types Exhibit 10: COTS/GOTS Project Example Exhibit 11: COTS/GOTS Document Artifacts Exhibit 12: COTS/GOTS Gate Reviews Exhibit 13: COTS/GOTS Testing Types Exhibit 14: Infrastructure Project Examples Exhibit 15: Infrastructure Document Artifacts Exhibit 16: Infrastructure Gate Reviews Exhibit 17: Infrastructure Testing Types Exhibit 18: Desktop Image Project Examples Exhibit 19: Desktop Image Document Artifacts Exhibit 20: Desktop Image Gate Reviews Exhibit 21: Desktop Image Testing Types Exhibit 22: Legacy System Project Example Exhibit 23: Legacy System Document Artifacts Exhibit 24: Legacy System Gate Reviews Exhibit 25: Legacy System Testing Types Exhibit 26: Simple Content-Based Web Site Project Example Exhibit 27: Simple Content-Based Web Site Document Artifacts Exhibit 28: Simple Content-Based Web Site Gate Reviews Exhibit 29: Simple Content-Based Web Site Testing Types Exhibit 30: Mainframe Document Artifacts Exhibit 31: Mainframe Gate Reviews Exhibit 32: Mainframe Testing Types Exhibit 33: SharePoint Document Artifacts Exhibit 34: SharePoint Gate Reviews iv CONTENTS

Exhibit 35: SharePoint Testing Types

OVERVIEW 1

1.0 OVERVIEW

Immigration and Customs Enforcement (ICE) established the System Lifecycle Management (SLM) Pre-defined Work Patterns to provide starting points for project teams in tailoring the work patterns of specific types of technology projects. By using pre-defined work patterns, Architecture Assurance is able to reuse and adapt a pre-tailored set of activities, document artifacts, and SLM gate reviews to create a customized project work pattern.

Depending on the type of project, Architecture Assurance may use of one of these pre-defined work patterns for a project:

Fast Track—Used for mission-critical projects with short schedules

Scrum—Used for projects that must respond to evolving requirements during the design and development of a system

COTS/GOTS—Used for commercial off-the-shelf/Government off-the-shelf (COTS/GOTS) products that are not customized

Infrastructure—Used for systems that are part of the ICE infrastructure

Desktop Image—Used exclusively for Desktop Images

Legacy System—Used for projects that desire to come into compliance with the SLM process but which have not historically followed the SLM process or its predecessors

Simple Content-Based Web Site—Used for small ICE Web site/applications that have minimal impact to the ICE environment

Mainframe—Used exclusively for mainframe systems

SharePoint—Used exclusively for applications or workflows developed to work with SharePoint

Architecture Assurance will choose a pre-defined work pattern that appropriately addresses the size, scope, risk, and context of the project.

After making a selection, ICE Architecture Assurance meets with the IT Project Manager at a tailoring review to ensure that the appropriate activities, document artifacts, SLM gate reviews, and types of testing are included. (The tailoring process is conducted for every new project and for every major release.)

During tailoring, an activity, document artifact, and/or SLM gate review may be added or removed depending on the specific characteristics or circumstances of the project. In some cases, only certain elements of a prescribed document artifact may be necessary, and they may be included in the contents of another document. (For example, the Requirements Traceability Matrix [RTM] could be included in the System Requirements Document [SRD].)

2 OVERVIEW

When tailoring is complete, the resulting customized project work pattern must be approved by ICE Architecture Assurance. Proposed changes to this project work pattern after approval by ICE Architecture Assurance must be submitted for consideration via the Request for Deviation (RFD) process.

FAST TRACK 3

2.0 FAST TRACK

The Fast Track work pattern supports projects intending to develop and deploy mission-critical functionality in a highly compressed schedule. To use Fast Track, a project must receive approval from Architecture Assurance.

A Fast Track project will typically follow one of the following three methodologies: abbreviated Waterfall, the first increment in an Incremental methodology, or the first iteration of an Iterative methodology.

By leveraging a subset of the standard SLM methodologies, Fast Track focuses on the most critical tasks and deliverables and defers less critical activities to later in the lifecycle. Increased risk is incurred by following the Fast Track process; however, this additional risk is accepted by the project to meet the imposed schedule constraints.

Following deployment, the project will be managed in the same manner as any other ICE initiative. These efforts serve to mitigate and reduce risks introduced by aggressive project deadlines. Because the concept and scope of subsequent enhancements are better understood, the methodology for future development efforts is determined, and the tailoring procedure is executed to determine the appropriate artifacts and reviews for the project.

If not already created, the project shall form a change control board (CCB) that bears the responsibility of monitoring deployment, managing corrective action, and moderating necessary enhancements.

In the event a further iteration of Fast Track is proposed for the project, authorization must again be obtained from Architecture Assurance.

2.1 Fast Track Project Profile

A project profile is the set of characteristics that Architecture Assurance assesses to determine if a project may use the Fast Track work pattern.

These characteristics include size, scope, risk, and context. Exhibit 1 provides an example of a project that could utilize the Fast Track work pattern.

Exhibit 1: Fast Track Project Example

Fast Track Project Example

Project X must be deployed in 90 days with a set of initial capabilities based on Government mandate or critical business need. There are additional enhancements, but the scope and functionality to be included in the enhancements is not yet known. It is critically important to field the initial capabilities as quickly as possible.

4 FAST TRACK

2.2 Fast Track Document Artifacts

Exhibit 2 identifies the SLM document artifacts associated with this work pattern.

Exhibit 2: Fast Track Document Artifacts

Fast Track Document Artifacts

Document Artifact To Be Provided Tailoring, Justification, and Comments

Project Tailoring Plan

Yes Collaborate with ICE Architecture Assurance to formalize the document deliverables and reviews for the project

Project Management Plan

Yes Include Procurement Strategy if procurement is necessary Update prior to Test Readiness Review (TRR) to include activities normally addressed in the Deployment Plan

Acquisition Plan Yes Ensure Acquisition Plan or Statement of Work (SOW) is on file with Acquisition Management Branch (AMB)

System Requirements

Document

Yes Provide a high-level description of how the system will operate Include the Requirements Traceability Matrix (RTM) Define system inputs/outputs, data requirements (include data elements, such as entities and attributes), operational requirements, and security requirements

Describe system interfaces by providing communications methods, capacity specifications, throughput specifications, security specifications, and integrity specifications

Requirements Traceability Matrix

No The System Requirements Document includes the required information of this document artifact

System Workload Analysis Document

If Necessary

Include if performance testing will be conducted or if any Office of the Chief Information Officer (OCIO) division raises concern with the application architecture or anticipated workload

Describe the system workload, estimate the capacity requirements, and define the impact on the system if system resources are unavailable or if it operates in a degraded mode

Interface Control Agreement

If Necessary

Include if any interfaces with other systems exist

Data Management Plan

No The System Requirements Document includes the required information of this document artifact

Information Technology Change

Request

If Necessary

Submit ITCR and/or Technology Insertions (TI) as appropriate for any new technology not on the ICE TRM or Department TRM respectively

FAST TRACK 5

Fast Track Document Artifacts

Document Artifact To Be Provided Tailoring, Justification, and Comments

Design Document Yes Diagram and describe system architecture Identify and describe commercial off-the-shelf (COTS) products

(software and hardware), configurations, and customizations Describe custom software design using high-level algorithms, class diagrams, sequence diagrams, or data/process flows Identify complete hardware inventory including physical locations, redundancies, and software dependencies, such as operating systems and drivers

Describe how system components and external systems are interconnected via networks and protocols

Provide physical data models and schema descriptions where data stores are used

Develop screen mockups for systems with substantial numbers of end users

Note: Much of this information may be provided as diagrams without extensive text

SEB Service Level Agreements

Yes Collaborate with production support teams in determining the level of support for the system in production

Data Conversion Plan

No If data require conversion, the Project Management Plan includes the required information of this document artifact

Training Plan Yes Coordinate with the business owner and the ICE Office of Training and Development (OTD) to provide strategic planning and oversight for training design, development, deployment, and evaluation; and also to provide training project management services

Training Strategies Worksheet

Yes Provide information about how the end users will be trained to operate the system

Development Test Plan

Yes Present the testing strategy, approach, and results from the project team at the TRR

Specify the test environment Define test cases required to verify the requirements and system changes of each release

Development Test Analysis Report

Yes Provide testing results of the requirements and system changes of each release

Version Description Document

Yes Include for each release of any product placed into the production environment

List CCB approved software changes and installation instructions

System Administration and Operations Manual

Yes Can be developed/updated following the release

User Guide Yes Can be developed/updated following the release

Deployment Plan No The Project Management Plan includes the required information of this document artifact

Notice of Intent to Release

Yes Required for all releases

Disposition Plan No Not applicable until project retirement

6 FAST TRACK

Fast Track Document Artifacts

To Be Document Artifact Tailoring, Justification, and Comments Provided

IAD Document Artifacts:

FIPS 199 Security

Categorization Worksheet

Interconnection

Security Agreement

Development Security Test and Evaluation (ST&E)

Report

Privacy Threshold Analysis

Privacy Impact

System of Record Notice

System Security

Plan

Security Risk Assessment

Contingency Plan

Development ST&E

The following documents generated by IAD:

Security Assessment Report

Certification Letter

Accreditation Letter

Yes Project team will work with Information Assurance Division (IAD) to address any security documentation requirements or issues (see the full list of IAD document artifacts to the left)

FAST TRACK 7

2.3 Fast Track Gate Reviews

Exhibit 3 describes the SLM gate reviews associated with this work pattern.

Exhibit 3: Fast Track Gate Reviews

Fast Track Gate Reviews

Gate Review To Be Held Tailoring, Justification, and Comments

Planning Review Yes A signed Project Tailoring Plan (PTP), initiated Project Management Plan (PMP), and initial project schedule required before system exits the Planning phase

In addition, the following System Lifecycle Management (SLM) document artifacts associated with this review must be provided early in the lifecycle:

System Concept of Operations (ConOps) section of the System Requirements Document (SRD)

Security Categorization Worksheet Training Strategies Worksheet Security Risk Assessment (SRA) System Security Plan (SSP)

Requirements Review

Preliminary Architecture and Design Review

Final Architecture and Design Review

Yes Requirements Review, Preliminary Architecture and Design Review (PADR), and Final Architecture and Design Review (FADR) will be combined

Test Readiness Review

Yes Held at the time of product hand-off to independent testing

Release Readiness Review

Yes Held prior to deployment

8 FAST TRACK

2.4 Fast Track Testing Types

Exhibit 4 identifies the independent testing efforts associated with this work pattern.

Exhibit 4: Fast Track Testing Types

Fast Track Testing Types

Test Type To Be Held Rationale

System Acceptance Test Yes All applications will be tested independently

System Security Test Yes All applications will be tested independently

Web Code Review If Necessary

If required by SEB review

Interoperability Testing If Necessary

If system introduces a software or hardware component that potentially conflicts with the existing implementation

Could be a script downloaded to the desktop, a new peripheral device, or other

Performance Testing No Not applicable

Section 508 Compliance Testing

Yes All ICE systems with a user interface must be scanned for Section 508 compliance

SCRUM 9

3.0 SCRUM

The Scrum work pattern supports projects that must respond to evolving requirements during the design and development of a system. To use Scrum, a project must receive approval from ICE Architecture Assurance.

Project teams should contact ICE Architecture Assurance early in the process to determine if the application can be supported by the Scrum work pattern.

A project following the Scrum work pattern will implement the Iterative methodology and will design and develop the system in 30-day cycles called sprints. Typically, in the Scrum process, each sprint produces a fieldable product. ICE departs from the traditional Scrum process by not requiring a fieldable product at the end of each sprint; however, ICE may introduce this requirement when deemed appropriate.

During the first few sprints, project teams execute planning, requirements definition, and preliminary design activities. These sprints conclude in a combined Planning Review/Requirements Review/Preliminary Architecture and Design Review (PADR). Before this review, the project should determine:

The high-level requirements, design, and architecture (technologies, frameworks, interfaces, and external dependencies)

The number of sprints necessary to accomplish the objectives defined in the SLM gate reviews, specifically the Final Architecture and Design Review (FADR) and the Test Readiness Review (TRR). This decision is made by the IT Project Manager.

The FADR is held at the conclusion of the sprint in which the architecture and design are expected to be finalized. The design should be a refinement of the design provided at the combined Planning Review/Requirements Review/PADR. The sprints continue until the TRR, where a handoff to independent testing takes place. The project may propose to ICE Architecture Assurance to continue using sprints for future system development and enhancement.

Exhibit 5 illustrates the expected maturation of requirements, design, and architecture throughout the implementation of the Scrum work pattern within the SLM process.

10 SCRUM

Exhibit 5: Scrum Requirements, Architecture, and Design Maturation

Requirements Architecture and Design Maximum Change Tolerance

SLM Milestones

Tolerance for Modification and Change

Time

Sprints Sprints Sprints

Planning Review/ Requirements

Review/ Preliminary

Architecture and Design Review

Final Architecture and Design

Review

Test Readiness

3.1 Scrum Sprints

To adhere to the Scrum process, for each sprint, project teams must have a sprint planning meeting, morning Scrum meetings, and a sprint review meeting. These reviews are open to all stakeholders and interested parties for contribution or observation. Reports provided at the sprint planning session and review meeting are to be recorded and disseminated to all key personnel as explicit artifacts of the Scrum process.

At the beginning of the sprint, stakeholders convene a sprint planning meeting for the purposes of prioritizing and subsequently selecting a set of tasks from a backlog that will form the basis of work during the sprint. (A backlog is the list of all functional and non-functional requirements.)

Projects may request that the user community be included as a part of the feedback loop that helps to prioritize and modify requirements as they are considered for sprint tasks.

The set of tasks removed from the backlog for inclusion in a particular sprint must be achievable during the course of a sprint. In the event that a

SCRUM 11

task item (requirement) is too broad to be completed, the task must be split into subtasks that will allow individual subtasks to be completed within a single sprint. When this set of tasks is determined, the sprint is initiated and the project team works to complete the tasks.

Each day of the sprint, a 15-minute morning Scrum meeting is held to discuss the goals for the day to achieve the tasks within the current sprint.

The task activities for the day are assigned, and any issues and risks are raised.

At the end of the sprint, a sprint review meeting is conducted. During this review, the project team evaluates the issues and progress/completion of each task item. After the sprint review is completed, the next sprint begins.

3.2 Scrum Considerations

Although the Scrum work pattern provides greater flexibility in defining requirements and designing a system, use of the Scrum work pattern introduces risk for deploying and supporting a system. This risk results from development occurring in the absence of fully solidified requirements, design, and architecture.

The requirements variability necessitates increased oversight of requirements maturation to support the creation of requirements artifacts that protect the interests of the Government. In addition, to support an implementation that is consistent with acceptable design and architectural standards, the project team must support a greater level of guidance and direction from the Architecture Division and production support teams.

To facilitate minimizing these risks, the Architecture Division will actively participate in sprint planning and sprint review meetings.

It is expected that the design and architecture are well formed by the PADR, and not significantly revised as the project progresses. Alterations from the architecture and design approved at the combined Planning Review/Requirements Review/PADR must be developed in conjunction with the Architecture Division.

Project teams may submit document artifacts for ICE Architecture Assurance assessment at the conclusion of any sprint, but must submit document artifacts for assessment at least 30 days prior to the last sprint to provide an opportunity for the project team to incorporate assessment feedback into the activities of the last sprint.

3.3 Scrum Project Profile

A project profile is the set of characteristics that ICE Architecture Assurance assesses to determine if a project may use the Scrum work pattern. These characteristics include size, scope, risk, and context.

12 SCRUM

Exhibit 6 provides an example of a project that could utilize the Scrum Development work pattern.

Exhibit 6: Scrum Project Example

Scrum Project Example

Project X has a defined set of capabilities but contains potentially changing requirements from the user community. The user community would like to steer application development as dictated by requirements that will emerge as the user community evaluates the functional, stable, and efficient development outputs of each sprint.

3.4 Scrum Document Artifacts

Exhibit 7 identifies the SLM document artifacts associated with this work pattern.

Exhibit 7: Scrum Document Artifacts

Scrum Document Artifacts

Document Artifact To Be Provided Tailoring, Justification, and Comments

Project Tailoring Plan

Yes Collaborate with ICE Architecture Assurance to formalize the document deliverables and reviews for the project

Project Management Plan

Yes State the number of sprints that will occur during the development effort and the testing effort with a high-level intention for each sprint

Identify the sprint in which product design is expected to be finalized

Acquisition Plan

Yes Ensure Acquisition Plan or Statement of Work (SOW) is on file with Acquisition Management Branch (AMB)

System Requirements

Document

Yes Provide a high-level description of how the system will operate During each sprint, as functionality is incorporated and removed from the backlog, the corresponding specifications are added to the System Requirements Document (SRD)

Note: The SRD is not expected to be complete at the time of Requirements Review. Rather, the SRD will be maintained as a living document that the project team will update at the completion of each sprint as functionality is incorporated and removed from the backlog. The SRD must be finalized prior to the Test Readiness Review (TRR).

Requirements Traceability Matrix

Yes Include standard information that allows tracing Include the priority assigned to each requirement in the

Requirements Traceability Matrix (RTM) During each sprint, as functionality is incorporated into the

SRD, add the corresponding specifications to the RTM

Note: The RTM is not expected to be complete at the time of Requirements Review. Rather, the RTM will be maintained as a living document, which the project team will update during each sprint as functionality is incorporated. The RTM must be finalized prior to the TRR.

SCRUM 13

Scrum Document Artifacts

Document Artifact To Be Provided Tailoring, Justification, and Comments

System Workload Analysis Document

Yes Describe the system workload, estimate the capacity requirements, and define the impact on the system if system resources are unavailable or if it operates in a degraded mode

Include if performance testing will be conducted, if any Office of the Chief Information Officer (OCIO) Division raises concern with the application architecture or anticipated workload, or if the application will share resources (database or application) with other applications currently in production

Note: The SWAD must be reasonably complete prior to the Final Architecture and Design Review (FADR) and must be finalized prior to the TRR.

Interface Control Agreement

If Necessary

Include if any interfaces with other systems exist Update the Interface Control Agreement (ICA) as sprints implement necessary interfaces

Data Management Plan

Yes Include the application logical data model, which contains the data requirements of a system (This includes an entity relationship diagram [ERD] and its supporting entity, attribute, relationship, and unique identifier reports)

Include the application physical data model, which contains the database design of a system (This includes the data schema diagram [DSD] and its supporting table, column, foreign key, and primary key reports)

Information Technology Change

Request

If Necessary

Submit ITCR and/or Technology Insertions (TI) as appropriate for any new technology not on the ICE TRM or Department TRM respectively

Design Document Yes Diagram and describe system architecture Identify and describe commercial off-the-shelf (COTS) products

(software and hardware), configurations, and customizations Describe custom software design using high-level algorithms, class diagrams, sequence diagrams, or data/process flows Identify complete hardware inventory, including physical locations, redundancies, and software dependencies, such as operating systems and drivers

Describe how system components and external system are interconnected via networks and protocols

Provide physical data models and schema descriptions where data stores are used

Develop screen mockups for systems with substantial numbers of end users

Note: In preparation for the initial Requirements Review / Preliminary Architecture and Design Review (PADR), much of this information may be provided as diagrams without requiring extensive text. As the project team nears the FADR, the design documentation should be further updated to include full descriptions of the intended architecture and design. Subsequent updates to the design specification are performed during subsequent sprints to reflect necessary updates.

SEB Service Level Agreement

Yes Collaborate with production support teams in determining level of support for system in production

Data Conversion Plan

If Necessary

Required only if data is being converted from one format to another

14 SCRUM

To Be Document Artifact Tailoring, Justification, and Comments Provided

Training Plan If Necessary

Coordinate with the business owner and the ICE Office of Training and Development (OTD) to provide strategic planning and oversight for training design, development, deployment, and evaluation; and also to provide training project management services

Training Strategies Worksheet

Yes Provide information about how the end users will be trained to operate the system

Development Test Plan

Yes Present testing strategy, approach, and results from project team at the TRR

Specify the test environment Define test cases required to verify the requirements and system changes of each release Maintain the Development Test Plan (DTP) to describe test activities performed during sprints that include Functional Qualification Testing (FQT) activities

Development Test Analysis Report

Yes Provide testing results of the requirements and system changes of each release

Maintain the Development Test Analysis Report (DTAR) to describe the results of test activities performed during sprints that include FQT activities

Version Description Document

Yes Include for each release of any product placed into the production environment

Installation procedures will be verified List CCB approved software changes and installation instructions The Version Description Document (VDD) must be made current and complete for each release prior to TRR

System Administration and Operations Manual

Yes Can be developed/updated following the release

User Guide Yes Can be developed/updated following the release

Deployment Plan Yes A standard deployment plan is required

Notice of Intent to Release

Yes Required for all releases

SCRUM 15

Document Artifact To Be Provided Tailoring, Justification, and Comments

16 SCRUM

3.5 Scrum Gate Reviews

Exhibit 8 describes the SLM gate reviews associated with this work pattern.

Exhibit 8: Scrum Gate Reviews

Scrum Gate Reviews

Gate Review To Be Held Tailoring, Justification, and Comments

Planning Review Yes A signed Project Tailoring Plan (PTP), initiated Project Management Plan (PMP), and initial project schedule required before system exits the Planning phase

A high-level explanation of how Scrum will be applied to the SLM process should be provided; ICE Architecture Assurance will identify the guidelines to follow for artifacts and milestones specific to Scrum

Requirements Review

Yes The scope and the prioritization of the requirements will be evaluated to determine the number of sprints necessary for the project; the number of sprints can then be included in the Project Management Plan (PMP); requirements are not expected to be complete at this time, but a reasonable scope definition is necessary to proceed

Additional Requirements Reviews may be held until the final requirements are captured

Preliminary Architecture and Design Review

Yes A statement of intentions should be provided with regard to technology, software (open source or commercial off-the-shelf/ Government off-the-shelf [COTS/GOTS]), and high-level design that describe how those technologies shall be applied; identify any interfaces, use of middleware, or other design and technology aspects of the project that are known at this time

Additional Preliminary Architecture and Design Reviews (PADR) may be held until the design becomes well established

Specify in which sprint the finalized design is expected; a Final Architecture and Design Review (FADR) will be scheduled to occur following the specified sprint

Final Architecture and Design Review

Yes The FADR is held when the project team reaches the pre-determined sprint in which the design is expected to be finalized

Design documentation that completely explains the technical intentions and approaches intended by the project team should be submitted and distributed prior to the FADR

Should subsequent sprints require substantial changes to product design or architecture due to unforeseen circumstances, an additional FADR will be held as appropriate

Test Readiness Review

Yes The Test Readiness Review (TRR) will be held at the time of product (or functionally complete sprint) hand-off to independent testing

Requirements specifications included in the following artifacts must be completed and up-to-date prior to the TRR; these artifacts formally determine the test scope and are required to initiate the independent testing process:

System Requirements Document (SRD) Requirements Traceability Matrix (RTM) Data Management Plan (DMP) System Workload Analysis Document (SWAD)

Release Readiness Review

Yes The Release Readiness Review (RRR) will be held prior to deployment

SCRUM 17

3.6 Scrum Testing Types

Exhibit 9 identifies the independent testing efforts associated with this work pattern.

Exhibit 9: Scrum Testing Types

Scrum Testing Types

Test Type To Be Held Rationale

System Acceptance Test Yes All applications will be tested independently Short, SAT-like functional tests may occur for each sprint within the Scrum A final SAT will occur after the final build is delivered

System Security Test Yes All applications will be tested independently

Web Code Review If Necessary

If required by SEB review

Interoperability Testing If Necessary

If system introduces a software or hardware component that potentially conflicts with the existing implementation

Could be a script downloaded to the desktop, a new peripheral device, or other

Performance Testing If Necessary

If system processing speed has a potential impact on business service delivery

If system resource usage potentially impacts other systems or the infrastructure

Section 508 Compliance Testing

Yes All ICE systems with a user interface must be scanned

COTS/GOTS 19

4.0 COTS/GOTS

The COTS/GOTS work pattern supports projects intending to implement a system that is already developed and will not be customized. This work pattern concentrates on documenting the decisions and tasks associated with selecting, acquiring, and implementing the COTS/GOTS product. To use COTS/GOTS, a project must receive approval from ICE Architecture Assurance.

A COTS/GOTS project will typically follow the Waterfall methodology.

Because the system will not need to be developed or customized, Design and Development activities are reduced.

In some cases, the selection of a COTS/GOTS product is determined prior to entering the SLM process. Examples include DHS directives to implement a particular product in the ICE environment and upgrades to products existing in the ICE environment. In cases where the evaluation of available products is unnecessary because the product has already been selected or is an upgrade to an existing product that has already been purchased, elements of this work pattern may be adjusted accordingly.

4.1 COTS/GOTS Project Profile

A project profile is the set of characteristics that ICE Architecture Assurance assesses to determine if a project may use the COTS/GOTS work pattern. These characteristics include size, scope, risk, and context.

Exhibit 10 provides an example of a project that could use the COTS/GOTS work pattern.

Exhibit 10: COTS/GOTS Project Example

COTS/GOTS Project Example

Project X is the implementation of a product selected by DHS as the enterprise standard to serve a particular business function (such as time accounting) that must be deployed within each DHS component.

COTS/GOTS 20

4.2 COTS/GOTS Document Artifacts

Exhibit 11 identifies the SLM document artifacts associated with this work pattern.

Exhibit 11: COTS/GOTS Document Artifacts

COTS/GOTS Document Artifacts

Document Artifact To Be Provided Tailoring, Justification, and Comments

Project Tailoring Plan

Yes Collaborate with ICE Architecture Assurance to formalize the document deliverables and reviews for the project

Project Management Plan

Yes Include procurement strategy if procurement is necessary Update prior to the Test Readiness Review (TRR) to include activities normally addressed in the Deployment Plan

Acquisition Plan

Yes Ensure Acquisition Plan or Statement of Work (SOW) is on file with Acquisition Management Branch (AMB)

System Requirements

Document

Yes Provide a high-level description of how the system will operate Include the Requirements Traceability Matrix (RTM) Define logical data elements, such as entities and attributes

Requirements Traceability Matrix

No The System Requirements Document includes the required information of this document artifact

System Workload Analysis Document

If Necessary

Include if performance testing will be conducted or if any Office of the Chief Information Officer (OCIO) division raises concern with the application architecture or anticipated workload

Describe the system workload, estimate capacity requirements, and define the impact on the system if system resources are unavailable or if it operates in a degraded mode

Interface Control Agreement

If Necessary

Include if any interfaces with other systems exist

Data Management Plan

No The System Requirements Document includes the required information of this document artifact

Information Technology Change

Request

If Necessary

Submit ITCR and/or Technology Insertions (TI) as appropriate for any new technology not on the ICE TRM or Department TRM respectively

Design Document Yes Identify the architecture, components, and technologies

SEB Service Level Agreements

Yes Collaborate with the production support teams in determining the level of support for system in production

Data Conversion Plan

If Necessary

Required only if data is being converted from one format to another

Training Plan Yes Coordinate with the business owner and the ICE Office of Training and Development (OTD) to provide strategic planning and oversight for training design, development, deployment, and evaluation; and also to provide training project management services

Training Strategies Worksheet

Yes Provide information about how the end users will be trained to operate the system

Development Test Plan

Yes Present the testing strategy, approach, and results from the project team at the TRR

Specify the test environment Define test cases required to verify the requirements and system changes of each release

Development Test Analysis Report

Yes Provide testing results of the requirements and system changes of each release

COTS/GOTS 21

COTS/GOTS Document Artifacts

To Be Document Artifact Tailoring, Justification, and Comments Provided

Version Description Document

Yes Include for each release of any product placed into the production environment

List CCB approved software changes and installation instructions

System Administration and Operations Manual

Yes Provide maintenance personnel and operations staff with the information necessary to maintain the system effectively (Vendor documentation is typically supplied in lieu of a Systems Administration and Operations Manual)

User Guide Yes Provide information that will enable the user to make full use of the system (A quick start guide, frequently asked questions (FAQ) sheet or similar material is frequently provided in lieu of a User Guide)

Deployment Plan No The Project Management Plan includes the required information of this document artifact

Notice of Intent to Release

Yes A Notice of Intent to Release (NIR) required for all Releases

COTS/GOTS 22

COTS/GOTS Document Artifacts

To Be Document Artifact Tailoring, Justification, and Comments Provided

AD Document

If Necessary

Project team will work with Information Assurance Division

COTS/GOTS 23

4.3 COTS/GOTS Gate Reviews

Exhibit 12 describes the SLM gate reviews associated with this work pattern.

Exhibit 12: COTS/GOTS Gate Reviews

COTS/GOTS Gate Reviews

Gate Review To Be Held Tailoring, Justification, and Comments

Planning Review Yes A signed Project Tailoring Plan (PTP), initiated Project Management Plan (PMP), and initial project schedule required before system exits the Planning phase

Requirements Review

Yes

Preliminary Architecture and Design Review

Final Architecture and Design Review

Requirements Review, Preliminary Architecture and Design Review (PADR), and Final Architecture and Design Review (FADR) will be combined; the reviews may be separated if deemed necessary by the Architecture Division

Any Information Technology Change Request (ITCR) associated with the infrastructure must be dispositioned prior to a combined review

Test Readiness Review

Yes Held at the time of product hand-off to independent testing (In many cases, only Interoperability Testing is conducted on commercial off-the-shelf/Government off-the-shelf [COTS/GOTS] products)

Release Readiness

Yes Held prior to deployment

COTS/GOTS 24

4.4 COTS/GOTS Testing Types

Exhibit 13 identifies the independent testing efforts associated with this work pattern.

Exhibit 13: COTS/GOTS Testing Types

COTS / GOTS Testing Types

Test Type To Be Held Rationale

System Acceptance Test If Necessary

Only if COTS/GOTS is customized

System Security Test Yes All applications will be tested independently Uncustomized COTS/GOTS will undergo security scan only

Web Code Review If Necessary

If required by SEB review

Interoperability Testing If Necessary

If system introduces a software or hardware component that potentially conflicts with the existing implementation

Could be a script downloaded to the desktop, a new peripheral device, or other

Performance Testing If Necessary

If system processing speed has a potential impact on business service delivery

If system resource usage potentially impacts other systems or the infrastructure

Section 508 Compliance Testing

INFRASTRUCTURE 25

5.0 INFRASTRUCTURE

The Infrastructure work pattern supports projects intending to implement a customized or non-customized COTS/GOTS product or a hardware product into the infrastructure. To use the Infrastructure work pattern, a project must receive approval from ICE Architecture Assurance.

Infrastructure projects often have unique documentation requirements or have existing documentation that may not obviously map to the ICE SLM conventions. During the tailoring process, the unique documentation requirements of an infrastructure project should be mapped to the appropriate or approximate types of SLM documents. The emphasis is on ensuring that the correct type of data is captured during the SLM process and not on a specific name or format of a document.

An infrastructure-specific pre-defined work pattern document and associated SLM document templates are being developed by ICE OCIO Architecture and Engineering Divisions. Until these are put into place, the interim solution noted in the above paragraph will remain in effect.

An infrastructure project will typically follow the Waterfall or Incremental methodology. (The Incremental methodology should be used particularly with dispersed deployments.)

5.1 Infrastructure Project Profile

A project profile is the set of characteristics that ICE Architecture Assurance assesses to determine if a project may use the Infrastructure work pattern.

These characteristics include size, scope, risk, and context. Exhibit 14 provides examples of projects that could use the Infrastructure work pattern.

INFRASTRUCTURE 26

Exhibit 14: Infrastructure Project Examples

Infrastructure Project Examples

Project X could implement one of the following:

Customization of commercial off-the-shelf/Government off-the-shelf (COTS/GOTS) products implementing ICE Office of the Chief Information Officer (OCIO) operational processes, such as security-related tools, directory services, firewall services, network address management services, and network operating systems (NOS)

Customization of COTS/GOTS products that provide the infrastructure supporting the performance of common business activities, such as e-mail, calendaring, document sharing, and voice and video communications

Configuration and implementation of desktop suites Deployment, operations, and maintenance of local area networks (LAN) and wide area networks (WAN) Configuration and deployment of equipment and hardware (such as desktop computers, servers, cables, routers, and switches) that provide the physical infrastructure for operating and maintaining business applications, OCIO operations-related tools, LANs, and the WAN

Configuration and deployment of satellite circuits and receivers Configuration, implementation, operations, and maintenance of the mainframe, database, E-Gov, and Web environments Configuration and implementation of data warehouses and repositories

5.2 Infrastructure Document Artifacts

Exhibit 15 identifies the SLM document artifacts associated with this work pattern. Note that for infrastructure projects, the emphasis is on ensuring that the appropriate information is captured. Infrastructure projects may have document names and formats that differ from the SLM naming conventions and templates; the tailoring process will document the mapping between documents. A typical example is the Version Description Document (VDD): For an infrastructure project, the VDD will typically detail the necessary build, setup, and configuration instructions to establish the baseline operating capability for the infrastructure component. Separate document artifacts for infrastructure projects will be created before the next version of this document.

In addition to the brief comments below, refer to the appropriate SLM templates to find a full description of the kind of information expected for each document artifact. These templates are available in the ICE Electronic Library (DOCUMENTS.ICE.DHS.GOV) under Governance Documents Home/Templates.

INFRASTRUCTURE 27

Exhibit 15: Infrastructure Document Artifacts

Infrastructure Document Artifacts

Document Artifact To Be Provided Tailoring, Justification, and Comments

Project Tailoring Plan

Yes Collaborate with ICE Architecture Assurance to formalize the document deliverables and reviews for the project

Project Management Plan

Yes To include detailed implementation plan on how the project will progress toward deploying the infrastructure

Acquisition Plan Yes Ensure Acquisition Plan or Statement of Work (SOW) is on file with Acquisition Management Branch (AMB)

System Requirements

Document

Yes Provide a high-level description of the purpose, function and intended operation of the infrastructure

Requirements Traceability Matrix

If Necessary

Case by case determination Typically, the System Requirements Document includes the required information of this document artifact

System Workload Analysis Document

No • Not applicable

Interface Control Agreement

If Necessary

If required per System Requirements Document (SRD)

Data Management Plan

If Necessary

Required if Extract, Transform, and Load (ETL) of data into the new environment will be required

Information Technology Change

Request

If Necessary

Submit ITCR and/or Technology Insertions (TI) as appropriate for any new technology not on the ICE TRM or Department TRM respectively

Design Document Yes Identify architecture, components, and technologies Describe all aspects of the design in full detail as may be applicable for the type of infrastructure

SEB Service Level Agreements

If Necessary

Only if Web or DBA hosting is required (on file with Systems Engineering Branch)

Data Conversion Plan

If Necessary

Required only if data is being converted from one format to another

Training Plan No PMP will include information about vendor knowledge transfer

Training Strategies Worksheet

No PMP will include information about vendor knowledge transfer

Development Test Plan

Yes Present the installation verification strategy and approach from the project team

Define test cases required to verify the requirements and system changes of each release

Development Test Analysis Report

Yes Present the installation verification results Provide testing results of the requirements and system changes of each release

Version Description Document

Yes Typically details the necessary build, setup, and configuration instructions to establish the baseline…