SLC -Final Draft - 2011.pdf

U.S. Department of Justice

Bureau of Alcohol, Tobacco, Firearms and Explosives Change

ATF H 7200.2B, Change 1

SUBJECT: SYSTEMS LIFE CYCLE HANDBOOK (DRAFT)

OPI: 306020

TO: All ATF Employees

1. PURPOSE. This change incorporates updates and revisions the Bureau of Alcohol, Tobacco, Firearms and Explosives (ATFs) Systems Life Cycle Handbook.

2. DISCUSSION/BACKGROUND FOR CHANGES.

a. The recent reorganization within OST has necessitated changes to the System Life Cycle document. The majority of these changes include updates to division titles, as well as new and/or changed roles within the organization.

b. Additionally, changes were made to the available work patterns based upon a recent review. These changes include the removal of outdated work patterns, and the addition of a new one.

c. Finally, a new appendix was added for the Complexity Matrix used by the CRM Team.

d. Each change is notated with an „*‟ symbol in the left margin (to denote the start of the change) and right margin (to denote the end of the change).

3. SPECIFIC PAGE CHANGES AND UPDATES.

a. Foreward: Paragraph titled „To‟ (Page 1) Paragraph 1. Purpose (Page 1) Paragraph 3. Background, subparagraphs a, b, and c (Page 1) Paragraph 4. Authorities, subparagraph f (Page 2) Paragraph 5. References, subparagraph b, g, i, j, and p (Pages 2, 3) Paragraph 6. Audits (Page 3) Paragraph 9. Questions (Page 4)

b. Table of Contents: Paragraph titles are changed or added, and exhibits are added.

Pages i through iii.

c. Chapter A.: Overview Paragraph 1. System Development, sub-paragraph B (Page A-1) Paragraph 2. Configuration Management, sub-paragraphs A, B, and C (Page A- 1) Paragraph 6. Enterprise Architecture (EA), sub-paragraphs F and G (Page A-4)

Paragraph 7. System Security Certification and Accreditation (C&A), sub-paragraph B.1 (Pages A-4, A-5) Paragraph 8. Roles and Responsibilities, multiple changes throughout section (Pages A-5 through A-11) Paragraph 9. Phases of System Life Cycle, sub-paragraph B (Page A-12) Paragraph 10. Quality Gates, sub-paragraph C and D (Page A-14) Paragraph 11. System Life Cycle Tailoring Work Patterns, sub-paragraph A (Page A-14) Paragraph 13. Reviews, sub-paragraph C (Page A-16) Paragraph 14. Programmatic Support Resulting from Project Activities, sub-paragraph B.2 (Page A-16)

d. Chapter B: Quality Gates Paragraph 25. All Quality Gates Always Performed, sub-paragraph D.2 (Page B-2)

e. Chapter C: Tailoring Work Patterns Paragraph 31. Purpose and Paragraph 32. Work Patterns (Pages C-1 through C-3) Table 3 - Combined Phases Based On Work Pattern Types (Page C-5)

f. Chapter D: System Concept Development Phase Paragraph 42. Entry Criteria (Page D-6) Paragraph 43. Procedure Description, sub-paragraphs A and B (Page D-6) Paragraph 44. System Concept Development Quality Gate, sub-paragraph C.2 (Page D-8)

g. Chapter E: Planning Phase Paragraph 53. Procedure Description, sub-paragraph B.2 (Page E-2)

h. Chapter F: Requirements Definition Phase Paragraph 62. Entry Criteria, sub-paragraph A (Page F-1)

i. Chapter G: Design Phase Paragraph 72. Entry Criteria, sub-paragraph A (Page G-1)

j. Chapter H: Development Phase Paragraph 82. Entry Criteria, sub-paragraph A (Page H-1)

k. Chapter I: Test Phase Paragraphs 91. Purpose, 92. Entry Criteria, and 93. Procedure Description (Pages I-1 through I-2) Figure 18 - Test Phase Exit Quality Gate (Page I-2)

l. Chapter J: Deployment Phase Paragraph 102. Entry Criteria (Page J-1)

m. Appendix B: Definitions Configuration Control Board (CCB) (Appendix B. Page 2) CRM (Appendix B. Page 3)

Independent Integrated Testing (IIT) (Appendix B. Page 5 IT Coordination Staff (Appendix B. Page 5) Program Management Review (PMR) (Appendix B. Page 7) Program Management Office (Appendix B. Page 7)

n. Appendix C: Complexity Matrix Complexity Matrix diagram (Appendix C. Page 1)

4. QUESTIONS. Any questions regarding this handbook should be directed to the Office of Science and Technology Chief Information Officer:

Dr. H. Richard Holgate Assistant Director

Office of Science and Technology Chief Information Officer

ATF H 7200.2B

1/08/2008

FOREWORD

TO: All Bureau Supervisors, System Owners and Contractors

1. PURPOSE. The purpose of the Systems Life Cycle (SLC) Handbook is to amplify the information provided in ATF‟s Systems Life Cycle Management Policy and provide guidance to the Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF) personnel for technical management and engineering practices to be used in planning, acquisition, operation, maintenance and replacement of Information Technology (IT) systems and services. This SLC is an internal document of the Office of Science and Technology (OST) of ATF.

2. CANCELLATION. ATF H 7200.2B Systems Development Life Cycle (SDLC) Handbook, dated 10/7/2003, is cancelled.

3. BACKGROUND. ATF is committed to developing and managing its information systems in a cost-effective manner and ensuring that its systems meet mission needs since such systems are the lifeblood of the Bureau. ATF depends on information to accomplish its mission. The Bureau‟s data and associated information systems are among its most valuable assets and are critical to ATF‟s ability to provide reliable information.

a. Information resources increasingly consume an even larger share of the Federal Budget.

New laws and regulations, in particular Information Technology Management Reform Act (ITMRA) of 1996, the Federal Information Security Management Act of 2002, and Office of Management and Budget (OMB) Circulars A-11 (July 21, 2010) and A-130 (February 1996), require ATF to ensure that its life cycle management procedures are comprehensive and up-to-date. Development of information systems is difficult, often complex, and expensive. Bureau system life cycle management requirements are designed to meet applicable Federal laws and regulations, ensure management involvement at key decision points, obtain and sustain Bureau commitment, and coordinate information systems-related activities.

b. The Systems Life Cycle Management procedure provides for the integration of system life cycle management with IT Investment Management, specifically Capital Planning and Investment Control (CPIC) and Enterprise Architecture (EA), Data Management (DM) and information security procedures and practices. As information systems are increasingly interconnected over the internet, security concerns have become of paramount importance. Security considerations, activities and documentation are required at every phase of the system life cycle.

c. The primary audience for this handbook includes those employees whose responsibilities include the direct responsibility for the acquisition, development, maintenance and ownership of system development using this procedure. It includes:

(1) Sponsoring organization/systems owners who authorize the funding for an IT solution and that represent the program office where the system resides; and

(2) Project leads who manage the overall system or manage the project through its life cycle.

4. AUTHORITIES. This handbook is issued under the authority of the ATF‟s Systems Life Cycle Policy. The following list includes the documents (laws, memoranda, OMB circulars, Change 1

[DATE]

etc.) which initiate, require, or are the legal mandates that are the basis for the ATF SLC procedures:

a. Chief Financial Officers Act, 1990.

b. Information Technology Management Reform Act (ITMRA), 1996, formerly the Clinger- Cohen Act, 1996.

c. Paperwork Reduction Act (PRA) of 1980, as amended by the Paperwork Reduction Act, 1995.

d. Federal Information Security Management Act (FISMA), 2002.

e. Government Paperwork Elimination Act (GPEA), 1998.

f. Government Performance and Results Act, 1997 (GPRA).

g. Public Law 93-579, Privacy Act of 1974, as amended.

h. High Performance Computing Act of 1991.

i. Executive Order 13011, Federal Information Technology, July 16, 1996.

j. Presidential Decision Directive 63 (PDD 63), Protecting America‟s Critical Infrastructures, May 1998.

k. Joint Federal Management Improvement Program, “Framework for Federal Financial Management Systems,” April 2004.

l. Section 508 of the Rehabilitation Act (29 U.S.C. 794d), as amended by the Workforce Investment Act of 1998 (P.L. 105-220), August 7, 1998.

m. OMB Circular A-130, Management of Federal Information Resources, November 28, 2000.

5. REFERENCES.

a. ATF H 7200.1A, ATF Enterprise Configuration Management Handbook, September 29, 2006.

b. ATF Information Technology (IT) Governance Policy ATF O 7200.2A, May 1, 2008.

c. ATF Order 1345.1, Records Management Program and Records Control Schedules (RCS), December 2, 2003.

d. Department of Justice (DOJ) Information Resources Management, Justice Management Division, System Development Life Cycle Guidance Document, January 2003.

e. National Institute of Standards and Technology (NIST) FIPS Pub 199, February 2004.

Standards for Security Categorization of Federal Information and Information Systems, located at http://csrc.nist.gov/publications/fips/index.html.

http://csrc.nist.gov/publications/fips/index.html

f. NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems, February 2006.

g. NIST Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, August 2008, located at http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol1-Rev1.pdf

h. NIST Special Publications for security guidance, located at http://csrc.nist.gov/publications/nistpubs/

i. NIST Special Publication 800-64, Security Considerations in the Information System Development Cycle, October 2008, located at http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf

j. OMB Circular A-11, Section 52, Information on Financial Management and Section 53, Revised, Information Technology and E-Government, 2008.

k. OMB Circular A-127, Section 8, Revised, Financial Management Systems.

l. OMB Circular A-130, Revised, Management of Federal Information Resources.

m. OMB Memorandum 00-07, Incorporating and Funding Security and Information System Investments, February 28, 2000.

n. OMB Memorandum 02-01, Guidance for Preparing and Submitting Security Plans of Action and Milestones, October 17, 2001.

o. Public Law 93-579, The Privacy Act of 1974, as amended.

p. U.S. Department of Justice Configuration Management Plan, Version 2.3, August 3, 2010.

6. AUDITS. Configuration Management audits will be conducted internally by the Program Management Office (PMO) of the Office of Science and Technology (OST). The audits will verify that procedures are being followed and that documentation is being completed and stored in the official document management tool of OST- IT Coordination Staff (ITCS).

7. ENTERPRISE ARCHITECTURE CONSIDERATIONS. For each phase of the SLC, Enterprise Architecture (EA) must be utilized and updated. For example, the Performance Reference Model (PRM) and Business Reference Model (BRM) are updated in the System Concept Development Phase; the Service Reference Model (SRM) is updated in the Development Phase.

8. REFERENCES AND GOVERNANCE PROCESSES. All references and governances processes described in this handbook are current. ATF supervisors are encouraged to determine if ATF governance processes or references have changed during the SLC process.

[DATE]

http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol1-Rev1.pdf http://csrc.nist.gov/publications/nistpubs/ http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf

9. QUESTIONS. Any questions regarding this handbook should be directed to the Office of Science and Technology Chief Information Officer:

Dr. H. Richard Holgate Assistant Director

Office of Science and Technology Chief Information Officer

Page i

TABLE OF CONTENTS

CHAPTER A. OVERVIEW Page

1. System Development A-1

2. Configuration Management (CM) A-1

3. Quality Assurance (QA) A-2

4. Risk Management (RM) A-2

5. Requirements Management A-3

6. Enterprise Architecture (EA) A-3

7. System Security Certification and Accreditation (C&A) A-4

8. Roles and Responsibilities A-5

9. Phases of System Life Cycles A-12 Figure 1 – System Life Cycle Management Framework A-13

10. Quality Gates A-14

11. System Life Cycle Tailoring Work Patterns A-14

12. COTS/GOTS Considerations A-15

13. Reviews A-15

14. Programmatic Support Resulting From Project Activities A-16 15 – 20 Reserved

CHAPTER B. QUALITY GATES

21. Collection of Completion Criteria B-1

22. Reviews and Oversight B-1

23. Inspection of Work Products B-1

24. Benefits B-1 Figure 2 – Quality Gates Integrated Into the SLC B-2

25. All Quality Gates Always Performed B-2

26. Sign-Off And Acceptance B-2

27. Review Descriptions B-3 Table 2 – SLC Quality Gates B-3 28 – 30 Reserved

CHAPTER C. TAILORING WORK PATTERNS

31. Purpose C-1

32. Work Patterns C-1

33. System Development Types C-3 Table 3 – Combined Phases Based On Work Pattern Types C-5 34 – 40 Reserved

CHAPTER D. SYSTEM CONCEPT DEVELOPMENT PHASE

41. Purpose D-1

42. Entry Criteria D-1

43. Procedure Description D-1

44. System Concept Development Quality Gate D-3 Figure 9 – System Concept Development Phase Exit Quality Gate D-3 45 – 50 Reserved

Page ii

CHAPTER E. PLANNING PHASE

51. Purpose E-1

52. Entry Criteria E-1

53. Procedure Description E-1

54. Conduct Planning Quality Gate E-3 Figure 10 – Planning Phase Exit Quality Gate E-3 Figure 11 – Planning Phase Quality Gate Process Flow E-4 55-60 Reserved

CHAPTER F. REQUIREMENTS DEFINITION PHASE

61. Purpose F-1

62. Entry Criteria F-1

63. Procedure Description F-1

64. Conduct Requirements Definition Quality Gate F-3 Figure 12 – Requirements Phase Exit Quality Gate F-3 Figure 13 – Requirement Phase Quality Gate 3 Process Flow F-5 65 – 70 Reserved

CHAPTER G. DESIGN PHASE

71. Purpose G-1

72. Entry Criteria G-1

73. Procedure Description G-1 Figure 14 – Design Phase Exit Quality Gate G-2 Figure 15 – Design Phase Quality Gate Review G-4 74 – 80 Reserved

CHAPTER H. DEVELOPMENT PHASE

81. Purpose H-1

82. Entry Criteria H-1

83. Procedure Description H-1

84. Conduct Development Quality Gate H-2 Figure 16 – Development Phase Exit Quality Gate H-3 Figure 17 – Quality Gate Process Flow H-3 85 – 90 Reserved

CHAPTER I. TEST PHASE

91. Purpose I-1

92. Entry Criteria I-1

93. Procedure Description I-1

94. Conduct Test Quality Gate I-2 Figure 18 – Test Phase Exit Quality Gate I-2 Figure 19 – Test Phase Quality Gate Process Flow I-3 95 – 100 Reserved

CHAPTER J. DEPLOYMENT PHASE

101. Purpose J-1

102. Entry Criteria J-1

103. Procedure Description J-1

Page iii

104. Conduct Deployment Quality Gate J-2 Figure 20 – Deployment Phase Exit Quality Gate J-2 Figure 21 – Deployment Phase Quality Gate #7 Process Flow J-3 105 – 110 Reserved

CHAPTER K. OPERATIONS AND MAINTENANCE PHASE

111. Purpose K-1

112. Entry Criteria K-1

113. Procedure Description K-1

114. Conduct O&M Quality Gate K-2 Figure 22 – Deployment Phase Exit Quality Gate K-2 115 – 120 Reserved

CHAPTER L. DISPOSITION PHASE

121. Purpose L-1

122. Entry Criteria L-1

123. Procedure Description L-1 124 – 130 Reserved

APPENDIX A. TAILORING AND WORK PATTERN CONSIDERATIONS

APPENDIX B. DEFINITIONS

APPENDIX C. COMPLEXITY MATRIX

Page A-1

CHAPTER A. OVERVIEW

1. SYSTEM DEVELOPMENT.

a. ATF‟s SLC Policy mandates the establishment of key aspects that must be properly controlled in order to effectively define, develop, control, and retire information systems within the Bureau. This handbook establishes what must be done in order to satisfy SLC policy requirements.

b. The philosophy used to develop this procedure was to infuse systems engineering and software/hardware development best practices into ATF culture, honoring the constraints under which the Bureau operates. To this end, this handbook looks to other mandated (and coordinated) processes to determine what and when they require formal review and approval in order to leverage these reviews and reduce the administrative requirements levied on System Owners.

c. This handbook is organized to provide a convenient reference for ATF individuals and offices responsible for executing system life cycle management. The body of this handbook provides a general overview and other key implementation information. This organization enables executives to understand the entire process without having to filter through the execution-level detail.

2. CONFIGURATION MANAGEMENT (CM).

a. ATF requires the performance of configuration management of all information system hardware, software, infrastructure and accompanying documentation throughout the system life cycle. The configuration management process provides the means for recording, reviewing, approving, and tracking change requests and problem reports for all configuration items. The procedures and processes in ATF H 7200.1A should be referred to and followed.

b. ATF Enterprise Configuration Management Handbook (ATF H 7200.1A) specifies the approach to configuration management for each project. The Enterprise Configuration Management (ECM) defines how the project will identify configuration items, and ensure configuration control, status accounting, and configuration audits for all configuration documentation, physical media, document storage and physical parts composing the system and its supporting systems (e.g., cable, power, and HVAC systems).

c. ATF projects performing CM are expected to perform the following activities:

(1) Perform configuration control in accordance with the guidelines of ATF H 7200.1A.

(2) Perform configuration identification.

(3) Perform configuration status accounting.

(4) Perform configuration audits and reviews by the Program Management Office.

Page A-2

3. QUALITY ASSURANCE (QA).

a. The Quality Plan lays the strategy for how the Project Lead intends to assure the quality of the resulting product. A Quality Plan defines the following:

(1) Responsibility for project quality.

(2) Key work products undergoing quality reviews.

(3) Approach used to review work products and product.

(4) How project/product quality will be measured and set forth the criteria for quality inspections.

(5) Typically, a Quality Plan or strategy is developed during the Requirements Definition Phase and updated as needed as the project progresses.

b. ATF projects performing quality assurance are expected to perform the following activities:

(1) Monitoring the project quality as implemented via the project Quality Plan.

(2) Performing periodic project audits for process and product compliance.

(3) Identifying corrective and preventative actions where there are identified compliance issues resulting from QA inspections.

(4) Measuring and reporting on ATF project quality trends.

4. RISK MANAGEMENT (RM).

a. Risk management begins in the Requirements Definition Phase and is continually applied throughout the entire project life cycle. The Project Lead must continually identify IT project risks and ways to reduce these risks to acceptable levels. During the Requirements Definition Phase these risks are primarily concerned with establishing a realistic commitment to addressing project requirements and obtaining the resources necessary to achieve project goals. The Project Lead will advise the System Owner on matters of significant risk and will coordinate risk management activities with key managers and analysts based upon their ability to control risk.

b. The Risk Assessment document provides detailed guidelines and assistance for Project Leads to establish a level of project risk assessment, planning, and management that is appropriate to the nature of the work expected to be performed during the project.

c. The tracking of risks in a risk identification list is a critical facet of successful system development management. Risk identification is used from the beginning of the project and is a major source of input for the risk assessment activity.

Page A-3

d. ATF projects performing risk management are expected to perform the following activities:

(1) Risk Assessment.

(2) Risk Mitigation.

(3) Evaluation and Assessment.

5. REQUIREMENTS MANAGEMENT.

a. Requirements management assists in controlling identification, definition and refinement of requirements as analysis proceeds from high level definition to detail specifications, and allocation to system and subsystem components.

b. Requirements gathering begin during the Requirements Definition Phase and should be iterative until requirements are detailed enough for system design and test plan preparation. Initial requirements are often high-level business requirements that must be decomposed down into greater detail that is needed for the later SLC phases of design, coding and testing. Often requirements that meet the need for acquisition will need further refinement for actual system development.

c. Requirements must be managed as they change and evolve throughout the system life cycle. The Project Lead will create and maintain a requirements database and a requirements traceability matrix to identify changes throughout the project life cycle. These work products are maintained and stored in the current ATF configuration tool.

d. ATF projects performing requirements management are expected to perform the following activities:

(1) Uniquely identify every requirement.

(2) Develop and use a requirements management matrix.

(3) Manage and control requirements.

6. ENTERPRISE ARCHITECTURE (EA).

a. ATF has established an EA policy that sets the framework for the relationship between IT solutions and the underlying EA architecture.

b. Enterprise Architecture considerations and compliance begin with the System Concept Development phase. The EA, information security, IT investment and the SLC are all interwoven to ensure the appropriate systems are procured and/or developed to support the business and mission of the organization.

c. ATF projects following EA procedures are expected to perform the following activities:

Page A-4

(1) Ensure EA requirements are built into the system concept early in the project life cycle during the Requirements Definition Phase.

(2) Scrutinize the critical design for EA compliance and proof of consistency with EA at all layers of the architecture, including business, application, data, and technology.

(3) Certify EA compliance. This Quality Gate is a certification of EA compliance during the Design Phase.

d. Governance is an integral part of EA to ensure that business needs and future enterprise solutions are identified and approved by the Bureau's business leaders. Governance includes mission-based architectures to include enterprise architecture planning, policies, and requirements based on business needs and performance measures as well as security management. Governance refers to the management and oversight processes that enable ATF to be responsive and adaptive to changes in directives, legislation and Bureau priorities.

e. Governance provides the oversight and sets the strategic direction for ATF security practices. Governance within ATF is provided through the establishment of security requirements, policies, and processes established in ATF's Automated Information Systems (AIS) Security Program, as well as through the SLC, EA and the CM processes.

f. The Enterprise Architecture Board/Information Resources Management Council (EAB) is a senior level decision-making body for information technology. The EAB provides budget and policy oversight for ATF's AIS Security Program.

g. The EAB and the Configuration Control Board (CCB) provide oversight and approval for all changes to ATF infrastructure and architecture, thus ensuring that change management procedures are followed for systems and applications.

7. SYSTEM SECURITY CERTIFICATION AND ACCREDITATION (C&A).

a. System Security Certification and Accreditation is a methodology for testing and approving AIS‟s for operation in ATF's environment. OMB Circular A-130 requires that all systems go through a certification and accreditation process to provide a form of quality control for systems processing information. The C&A process ensures that the necessary security features are in place so that all security vulnerabilities are addressed prior to system operation in a production environment.

b. Certification and accreditation, although related, are not the same processes, nor do they have the same objectives. A detailed description of each process follows:

(1) Certification is a short-term activity that is repeated after any significant AIS related change. It is a prerequisite for accreditation and involves comprehensive testing and evaluation of technical and non-technical AIS security features and of other safeguards used in support of the accreditation process. Certification establishes the extent to which a particular AIS design and implementation meet a specified set of security

ATF H 7200.2B

Change 1

Page A-5 requirements. Certification primarily addresses software and hardware security safeguards, but it also considers those procedural, physical, and personnel security measures employed to enforce the AIS Security Program.

(2) Accreditation is the authorization and approval granted to AIS to process Sensitive But Unclassified (SBU) information or classified data in an operational environment, for a period of up to three (3) years.

Accreditation is made based on certification stipulating that the system meet specific technical requirements for achieving adequate data security. Accreditation authorizes AIS to operate based on the facts, plans, and schedules presented during the certification process.

(3) Accreditation cannot occur without a Security and Vulnerability analysis and an accompanying Security Plan that identifies the means to mitigate threat/vulnerability as mitigate risks by threats and vulnerabilities.

8. ROLES AND RESPONSIBILITIES.

a. Enterprise Architecture Board in addition to other responsibilities is responsible for:

(1) Reviewing all directorate-level Customer Business Needs (CBN) developed by the Office of Science and Technology (OST).

(2) Supporting full integration between EA and Capital Planning and Investment Control (CPIC) processes in the areas of strategic planning, portfolio management of new IT initiatives.

(3) Requesting the Architecture Working Group (AWG) provide Technology and Pricing recommendations to support customer business plans and needs; overseeing the Architecture Working Group (AWG) and topic-based steering committees; and, making final determinations to task the Architecture Working Group (AWG) for technical review and solution recommendations.

(4) Requesting recommendations of the best solutions.

(5) Reviewing CCB approved, disapproved and implemented initiatives.

(6) Reviewing IT project initiatives as presented by the Program Management Office (PMO).

(7) Making decisions on the acquisition and use of information technology.

(8) Establishing Bureau IT priorities.

(9) Reviewing and approving the annual IT spend plan, including funding for new initiatives from a strategic business perspective.

(10) Approving Bureau information resources management policies.

Page A-6

(11) Considering Customer Proposals.

(12) Approving/denying funding for development of unfunded CBPs.

b. Customer Relationship Management Representatives are responsible for:

(1) Assisting ATF directorates with documenting the needs though the development of a Customer Business Needs (CBNs) document.

(2) Reviewing IT requests against CBN.

(3) Preparing Customer Action Forms and Rough Order of Magnitude (ROM) Cost Estimates for EAB evaluation.

(4) Preparing customer to present to the Governance Boards.

(5) Coordinating with the PMO to ensure approved projects are ready for execution.

(6) Being the primary interface for customer and OST interests to ensure both organizations interests are represented.

(7) Discovering long term customer needs/requirements.

(8) Shaping customer needs and expectations to maintain an alignment with IT strategy and architecture.

(9) Guiding customers through EA/governance processes and development of overall business case/cost analysis.

(10) Providing a single entry point/face to customer for:

a. First point of escalation when things don‟t work.

b. New project demand.

(11) Advocate for customer.

(12) Perform customer outreach and facilitate customer education, including product and service catalog.

(13) Conduct customer surveys to ensure internal business entities are satisfied with all IT solutions they use.

(14) Coordinate customer issues and needs within OST, and ensure problem resolution.

c. The Strategic Leadership Team (SLT) is responsible for:

(1) Identifying business strategies, initiatives and programs to achieve the goals and objectives outlined in the strategic business plan.

Page A-7

(2) Serving as the Bureau‟s Investment Review Board (IRB).

(3) Working with the Chief Information Officer (CIO) and the recommendations of the EAB to provide profiles of information resources and show how system initiatives link back to strategic objectives.

d. The System Owner (SO) is responsible for:

(1) Maintaining active senior level involvement through the EAB and/or steering committee throughout the development of the system.

(2) Initiating the project request for a new information system or modification to an existing system.

(3) Participating in project review activities and reviewing project work products.

(4) Selecting a SO as the key participant on the project team with responsibility for defining the functional/user needs.

(5) Describing functional requirements to the Project Lead/Team and interfacing with others.

(6) Ensuring that the final product meets user requirements.

e. The Chief, ITCS is responsible for:

(1) Chair of the CCB.

(2) Participating in the EAB.

f. The Project Lead is responsible for:

(1) Coordinating all management and technical aspects of the development effort.

(2) Developing the project plan, completing the project within schedule and budget, meeting customer needs, reporting to the steering committee as required, and developing the project charter.

(3) Providing detailed work assignments, making sure written tasks exist for all work.

(4) Developing measurement criterion that defines what constitutes acceptable performance of each task.

(5) Coordinating and/or performing system planning, requirements definition, design, testing and deployment activities.

(6) Scheduling and directing milestone reviews and participating in reviews conducted by independent staff or review committee.

Page A-8

(7) Resolving problems related to all phases.

(8) Ensuring that the project produce required work products in accordance with the guidelines in this handbook, and that all work products are stored in OST-approved central repository.

g. The Configuration Control Board (CCB) is responsible for:

(1) Reviewing and approving maintenance-based hardware/software changes of existing systems.

(2) Reviewing and approving Request for Changes (RFCs) for new products/systems after EAB approval.

(3) Maintaining RFC Database and RFC OnLine

(4) Reporting to the EAB.

h. System Maintenance Division (SMD) is responsible for:

(1) Selecting the appropriate work patterns for all their projects and following the guidance of this SLC.

(2) Scheduling, executing, and verifying production job streams, distributing specified outputs, handling other production control activities, maintaining and monitoring centralized mainframe database management system software and runtime environments.

(3) Maintaining and controlling the physical infrastructure and the operating environment

(4) Interfacing with the computer facility that hosts the system.

i. System Development (SDD) Integration/Validation Office is responsible for:

(1) Independently verifying and validating that processes used by the development team, and the products produced by the processes, are complete, correct, and ready for deployment in a production environment.

(2) Ensuring that products of each phase of the SLC are fulfilled and the final system or component complies with specified requirements.

j. The Project Lead is appointed by OST management and is responsible for:

(1) Both the responsibility and accountability for project execution.

(2) Along with the System Owner, the selection of resources for the Integrated Project Team (IPT).

(3) Preparing and presenting a project status review for the System Owner, and other stakeholders at the end of each Life Cycle Phase

Page A-9

(4) Meeting project objectives.

(5) Managing the overall system and managing the project through its life cycle.

(6) Continually identifying IT project risks and finding ways to reduce these risks to acceptable levels.

k. Project Team Members are responsible for accomplishing assigned tasks as directed by the Project Lead (regardless of the organization of permanent assignment).

l. Architectural Working Group (AWG) is responsible for:

(1) Reporting directly to the EAB.

(2) Assigning (by the AWG division chiefs) resources for specific projects/analyses/tasks assigned by the EAB.

(3) Conducting internal review and market research.

(4) Evaluating reports and cost analysis on a primary and two alternative solutions.

(5) Recommending solutions/products to the EAB, by the AWG Chairperson.

m. Program Management Office (PMO) is responsible for:

(1) Reporting status directly to the EAB.

(2) Conducting reviews of life cycle products and providing feedback to the project team.

(3) Participating in developing the disposition plan for the system.

(4) Ensuring that system life cycle phase Quality Gates have been conducted.

(5) Promoting Configuration Management Baselines.

(6) Administration of an approved central configuration management repository for all of ATF.

(7) Establishes policy, plans, processes, guidance, etc. for the PM discipline.

(8) Centrally track performance of projects.

(9) Ensures adherence to the SLC, project management best practices, etc.

(10) Brief EAB on status of projects.

(11) Establish training and certification requirements.

Page A-10

(12) Coordinate training budget.

(13) Manage the process of Gate reviews and Configuration Management according to the SLC.

n. The Information Systems Security Officer (ISSO) is responsible for:

(1) Participating in functional requirement reviews.

(2) Participating in design reviews to ensure security measures are being appropriately addressed in the design and development of the system.

(3) Reviewing security-related documentation (i.e., security plans, risk assessments, contingency plans, security tests) to ensure that security requirements are addressed.

(4) Defining and specifying the security of the system.

(5) Determining internal control requirements.

(6) Identifying security standards applicable to the development of the system including access, encryption, security architecture, and privacy.

(7) Participating in test plans and system testing, and conducting a Security Vulnerability Threat analysis.

(8) Ensuring system certification and accreditation prior to its operational use.

o. The Contract Specialist is responsible for:

(1) Providing expert advice to the Project Lead in planning for the acquisition of needed resources other than personnel. These resources include hardware, software, and contractor support services.

(2) Participating actively in other procurement activities of the system project.

p. The Data Manager is responsible for:

(1) Constructing and maintaining an approved list of data entities and attributes.

(2) Maintaining a repository of data models and data architectures.

(3) Reviewing data entities and attributes for conformance to ATF naming standards.

(4) Participating in system demonstrations for the user organization and management.

(5) Providing technical guidance and subject matter expertise to assist database administrators in converting the logical data model to a physical data model.

Page A-11

(6) Reviewing physical database design to ensure that it accommodates the logical design requirements.

(7) Approving or disapproving logical or physical designs.

(8) Conducting reviews of Commercial-off-the-Shelf (COTS) and Government-off-the-Shelf (GOTS) systems for compatibility with ATF standards and data infrastructure.

q. The Component Configuration Manager is responsible for:

(1) Establishing procedures for configuration and change control.

(2) Maintaining a complete file and log of all change requests, including requests to modify system characteristics that are not yet approved and baselined, as well as requests to modify approved configuration plans.

(3) Recording the disposition of all change requests, including approval/disapproval, and completion and deployment of the change.

(4) Preparing periodic reports of configuration status, as needed and providing assistance and support to the performance of configuration audits.

(5) Developing and maintaining the program library of life cycle products.

(6) Providing physical control over baseline documentation.

(7) Managing the movement of software and data among development, test, training, and production environments.

(8) Conducting periodic CM audits and Status Accounting reviews.

r. Oversight Stakeholders are responsible for CIO oversight, advice, and counsel to the Project Lead for the conduct and requirements of the planning effort.

Additionally, oversight provides information, judgments, and recommendations to ATF decision-makers during project reviews and in support of project decision milestones.

s. The Help Desk personnel are responsible for providing support for the day-to-day use of the system. Help Desk personnel should be kept informed of all changes or modifications to the system. Help Desk personnel are contacted by the user and System Owner when questions or problems occur with the daily operations of the system. Help Desk personnel need to maintain a level of proficiency with the system.

t. Customers are responsible for sharing with the systems owner the need for improvements or the existence of problems. Some users live with a situation or problem because they feel they must. Customers may feel that change will be slow or disruptive. Some feel the need to create work-arounds. A customer has

Page A-12 the responsibility to report problems or make recommendations for changes to a system.

9. PHASES OF SYSTEM LIFE CYCLE.

a. The ATF System Life Cycle is composed of nine phases. Figure 1, System Life Cycle Management Framework, identifies these phases and provides a context for them in relation to ATF‟s CPIC and security processes. The diagram also identifies the principal executive-level reviews that apply during the system life cycle. These Quality Gates are go/no-go decision points that require management approval for continued support. The diagram also establishes that project-level reviews will be conducted throughout the life cycle. These reviews ensure that these procedures are being followed. They are conducted in accordance with the instructions in the exhibits that addressing the nine phases of the SLC. Evidence of these reviews will be submitted quarterly, along with the system‟s Earned Value Management (EVM) information, providing the necessary feedback mechanism between major Quality Gates.

b. The nine phases of the Full SLC are:

(1) System Concept Development Phase (Chapter D).

(2) Planning Phase (Chapter E).

(3) Requirements Definition Phase (Chapter F).

(4) Design Phase (Chapter G).

(5) Development Phase (Chapter H).

(6) Test Phase (Chapter I).

(7) Deployment Phase (Chapter J).

(8) Operations & Maintenance Phase (Chapter K).

(9) Disposition Phase (Chapter L).

Page A-13

Figure 1 – System Life Cycle Management Framework

Select Control

S L

C M

C P

IC

2 4 5

Evaluate

Planning Design Development

System Life Cycle Management Phases

Capital Planning and

Investment Control Phases

1 Quality Gates

Legend:

Operations &

Maintenance

Phase

Deployment Phase

S e c u ri ty

Certification Accreditation C& A Maintenance

Pre- Select

Security Certification and

Accreditation Phases

Initiation

Requirements

Project Reviewss

Test

Deployment

Requirements

Definition Phase

Planning

Phase

System Concept

Development

Test

Phase

Development

Phase

Design

Phase

Disposition

Phase

1 8

System Concept Operations

Page A-14

10. QUALITY GATES.

a. Quality Gates are a collection of completion criteria and sufficiency standards representing the satisfactory execution of a phase of a project. Quality Gates provide early control of project quality. To prevent quality from becoming an issue in the later phases of a project, quality gates are inserted between pre-determined phases of the SLC.

b. In order to provide adequate executive oversight and to ensure that appropriate OMB and ATF regulations are observed, the SLC requires periodic executive level review of projects. In the SLC, these reviews are called Quality Gates.

c. Consistent with the SLC strategy and the Work Pattern selected, there are up to nine Quality Gates, which are linked to other processes that mandate executive review. Templates for the Quality Gates are on the OST Program Management Office IntraWeb.

d. A group calendar will be used to maintain and review the scheduling of all Quality Gates.

11. SYSTEM LIFE CYCLE TAILORING WORK PATTERNS.

a. System Life Cycle tailoring work patterns are used to determine the appropriate development methodology and appropriate work products, dependent upon the scope of the project. Project deliverables will vary according to the work pattern that is selected.

b. This handbook provides a complete and robust list of work products which are necessary to properly manage and control a large-scale, mission critical, high risk system. However, not all ATF systems fall into this category. While all projects require adequate documentation and work products to ensure that they are progressing appropriately and to provide management enough information to make informed decisions concerning the future of the system, lower risk projects do not need as much documentation to maintain appropriate oversight and control.

c. There are certain procedures and work products that can never be tailored out of a SLC strategy. These include:

(1) Clear high level functional requirements.

(2) Processes and/or procedures that ensure the system will be able to operate within the current and planned IT infrastructure and architecture.

(3) Adequate system testing.

(4) Adequate user training.

(5) Operations and maintenance documentation.

d. The tailoring strategy is determined during the Planning Phase.

Page A-15

12. COTS/GOTS CONSIDERATIONS.

a. The ITMRA directs agencies to consider and give preference to the use of Commercial-off-the-Shelf (COTS) software when making plans to procure information systems. The value of COTS and Government-off-the-Shelf (GOTS) products (i.e., systems developed by and for one Government agency that are easily tailored to suit the needs of another agency) is that the COTS/GOTS can dramatically reduce costs and development time. It is worth consideration if the COTS/GOTS system satisfies a large portion of an organization‟s requirements and/or the organization is willing to modify its requirements so as to be able to adapt to the COTS/GOTS product design.

b. There is an occasional misconception among the end-user community and by information technology professionals that COTS products do not need to observe an agency‟s SLC because some outside organization, usually the vendor, is responsible for determining what features and functionality the system will have.

This misconception ignores the responsibility an agency has for performing a proper mission needs assessment prior to making certain capital investments.

Even if the initial purchase price is below an agency threshold for taking a more robust approach to the SLC for COTS products, many people neglect to consider that operation and maintenance costs are also part of the system life cycle cost that triggers oversight levels.

c. When considering how to tailor the SLC for use with COTS, Project Leads should also consider whether or not the COTS software documentation satisfies the requirements for system documentation. If the necessary information is contained in the standard vendor documentation, Project Leads do not have to develop and manage a new documentation set.

d. Licensing and annual maintenance issues should also be considered for all COTS/GOTS products. The actual cost of the software may prove to be only a small cost when these considerations are taken into account.

e. COTS software will be examined to ensure that it does not contain features that might be detrimental to AIS security. Appropriate testing will be performed to assure that all COTS software conforms to ATF minimum-security requirements.

f. Customized COTS software (commercially procured software to which in-house modifications have been made) require design reviews and system tests.

Systems using such software must be examined to ensure that the configurable or modified software does not contain features that might be detrimental to AIS security. Appropriate testing will be performed to assure that all customized COTS software conforms to ATF minimum-security requirements.

13. REVIEWS.

a. The SLC calls for regular reviews on two levels: Quality Gates and project level reviews. The purpose of these reviews is to enable key stakeholders to confirm that the system under development is the system that needs to be built, that it is being built correctly, and that appropriate quality standards are being applied.

ATF H 7200.2B

Page A-16

b. The reviews must address the required elements taking into account approved tailoring strategies. At the conclusion of the review, the Project Lead and the System Owner must sign off on the completed review, forwarding the evidence of the review to OST with the next quarterly Earned Value Management (EVM) submission following the completion of a project level review.

c. The OST PMO will conduct random audits of submitted project level review data on a quarterly basis. If errors are found in the submissions, OST will work with the Chief, IT Coordination Staff (ITCS), the System Owner, and responsible Project Lead to bring the system into compliance.

14. PROGRAMMATIC SUPPORT RESULTING FROM PROJECT ACTIVITIES.

a. The SLC documentation is intended to provide the roles, responsibilities, actions, and authorities for System Development and Software Operations and Maintenance activities at a project level.

b. It is recognized that many project activities have an effect upon wider ranging programmatic activities. Examples of such activities may include:

(1) Updating of the Technical Architecture and Technical Reference model to reflect impacts of projects implemented at ATF.

(2) Updating of the Project Master Schedule as an overall view of the projects in process in the OST.

(3) Updating of Minimum Security Requirements (MSR) documentation.

(4) Alignment of business functions within the Business layer of the EA.

(5) Updating of CBP to reflect newly approved projects that are in accordance with the CBP goals and strategies.

c. While the preceding list is merely a representative group of programmatic needs or requirements, it is recognized that there are many others within ATF.

d. It is not the intention of the SLC documentation to provide guidance or

e. Programmatic guidance, policies and procedures are addressed in programs that are established and distributed Bureau-wide or directorate-wide.

Notwithstanding, readers are cautioned to become thoroughly familiar with such policies and procedures so that appropriate interfaces can be established for project activities that may potentially affect ATF programs.

15 – 20 RESERVED

Page B-1

CHAPTER B. QUALITY GATES

21. COLLECTION OF COMPLETION CRITERIA.

Quality Gates are a collection of completion criteria and sufficiency standards representing the satisfactory execution of a phase of a project. Quality Gates provide better and earlier control of project quality. To prevent quality from becoming an issue in the later phases of a project, quality gates are inserted between pre-determined phases of the SLC.

22. REVIEWS AND OVERSIGHT.

a. The Quality Gates chosen provide sound review and oversight of ATF‟s information technology projects. Each Quality Gate confirms the performance of necessary activities through the review of prepared work products. Therefore, the risks of continuing the project can be fully evaluated and accepted by the responsible party.

b. The Quality Gates selected are closely tied to the agency‟s CPIC, EA, and security activities in order to take full advantage of the policies and procedures already established to provide IT project oversight and to minimize redundancy and duplication.

23. INSPECTION OF WORK PRODUCTS.

a. At the end of specific phases, there is a Quality Gate in which the work products and other documents are inspected and a judgment is made as to whether these are complete and the project should be allowed to proceed on to the next phase.

b. If there are incomplete or defective products, this does not necessarily terminate the project, but it does mean that the project cannot be allowed to move on to the next phase, until the “quality” problems are fixed.

24. BENEFITS.

Quality Gates can be highly effective on any project. There are distinct advantages that make Quality Gates valuable. Those advantages include:

a. Enabling Project Leads to continuously communicate the process and build quality directly into the project.

b. Detecting errors early in the process, since Quality Gate reviews prevent the project from moving to the next phase of the SLC until errors and quality issues are corrected.

Page B-2

Figure 2 – Quality Gates Integrated into the SLC

System

Concept

Development

Planning Requirements Design Development Test Deployment Operations &

Maintenance Disposition

SLC Phase

1 Quality Gate

25. ALL QUALITY GATES ALWAYS PERFORMED.

a. Regardless of the development model chosen for a project, all Quality Gate reviews must be performed. Quality Gates are only valuable if enforced.

Adhering to the use of Quality Gates for tracking task completion facilitates project tracking overall and establishes greater credibility to the status reporting process. You cannot proceed to the next Quality Gate until the previous Quality Gate has been completed.

b. Formal checklists are used throughout the life of a project. Checklists can be revised as needed, but the process is documented.

c. Using checklists…