Appendix_1 _NARA_SDLC.pdf

NARA Systems Development

Life Cycle (SDLC)

Methodology

NATIONAL ARCHIVES AND RECORDS ADMINISTRATION

November 27, 2013 V e r s i o n 1 . 6

Enterprise Architecture NARA SDLC Methodology Version 1.6

SDLC.Methodology.docx November 27, 2013 2

Table of Contents 1 Introduction

1.1 Purpose of NARA’s SDLC

1.2 Context of NARA’s SDLC

1.3 Overview of NARA’s SDLC

1.4 Initiating a Project

1.5 Reference Documents

2 SDLC Stages and Gate Reviews

2.1 SDLC Stages

2.2 SDLC Gate Reviews

2.3 Preparing for SDLC Gate Reviews

3 SDLC Activities 4 SDLC Tailoring

4.1 Tailoring Plan

4.2 Tailoring Concepts

4.3 Tailoring Process

4.3.1 Determining the Work Stream Type

4.3.2 Determining the Project Type

4.3.3 Tailoring SDLC Work Stream Tasks

4.3.4 Aligning Work Products to Expected Outcomes

4.3.5 Tailoring Work Product Templates

Appendix A – Detailed SDLC Tasks and Work Products A.1 Business Needs Analysis A.2 Concept Development A.3 Requirements Analysis A.4 Design A.5 Development A.6 Deployment Preparation A.7 Operations and Maintenance A.8 Retirement

Appendix B – SDLC Work Stream Templates B.1 New Custom Developed or COTS Application Work Stream Template B.2 New SaaS Application Work Stream Template B.3 Application Upgrade Work Stream Template B.4 Application Maintenance Work Stream Template B.5 New IT Infrastructure Capability Work Stream Template B.6 New Platform as a Service (PaaS) / Infrastructure as a Service (IaaS) Work Stream Template B.7 Major IT Infrastructure Upgrade Work Stream Template B.8 IT Infrastructure Refresh Work Stream Template

Appendix C – SDLC Tailoring Plan Worksheets Appendix D – NARA Stakeholder Perspectives on SDLC Tasks

D.1 CPIC Perspective on SDLC Tasks D.2 Data Administration Perspective on SDLC Tasks D.3 Security Perspective on SDLC Tasks D.4 Records Management Perspective on SDLC Tasks D.5 IT Operations Perspective on SDLC Tasks

Appendix E – Terms and Acronyms

SDLC.Methodology.docx November 27, 2013 3

1 Introduction

1.1 Purpose of NARA’s SDLC

It is widely recognized that instituting a Systems Development Life Cycle (SDLC) process can facilitate the development of information systems, and enable more effective management of Information Technology (IT) projects. OMB Circular A-130 mandates that Federal agencies establish an SDLC process to guide the management of the programs in their IT investment portfolio, to facilitate transition plans as specified by their Enterprise Architecture (EA), and to ensure that information assurance (IA) and risk management considerations are addressed by all programs and projects.

The SDLC process is used to manage projects that are intended to develop, deploy, and operate information systems and Information Technology (IT) infrastructure capabilities in accordance with business needs. As stated by the International Council on Systems Engineering (INCOSE), “The purpose in defining the system life cycle is to establish a framework for meeting the stakeholders’ needs in an orderly and efficient manner. This is usually done by defining life-cycle stages and using decision gates to determine readiness to move from one stage to the next”.1 Using an SDLC helps enterprises to “orchestrate the development of a solution from requirements determination through operations and system retirement by assuring that domain experts are properly involved, that all advantages and opportunities are pursued, and that all significant risks are identified and mitigated”.2 NARA’s SDLC methodology draws heavily from concepts presented in the INCOSE Systems Engineering Handbook - and it is highly recommended that the INCOSE Handbook be used as a supplemental reference.

INCOSE defines a system as “an integrated set of elements, subsystems, or assemblies that accomplish a defined objective”.3 NARA’s SDLC is intended to address all aspects of a system including hardware, software, people, and processes – it is not intended to address only the development of software. Projects are free to integrate specific software development methods (e.g., Scrum, Extreme Programming, RUP, RAD) within the overall system development life cycle. This document defines NARA’s SDLC methodology. Subsequent sections of the document will:

(a) Show the context of the SDLC as it relates to other agency Information Resources Management (IRM) processes, (e.g., Capital Planning and Investment Control and EA);

(b) Explain the stages of the SDLC and the various technical and management processes that comprise it;

(c) Describe the gate reviews used to assess project performance and system maturity; and

(d) Provide guidance on how to tailor the SDLC to the specific needs of a project.

1 See the INCOSE Systems Engineering Handbook, Version 3.2.1, January 2011, pp. 21.

2 Ibid.

3 Ibid., Pg. 5.

SDLC.Methodology.docx November 27, 2013 4

1.2 Context of NARA’s SDLC

NARA’s SDLC process is established under the auspices of the agency Chief Information Officer (CIO). The SDLC process is a structured and integrated set of activities used to:

(a) Conceptualize, implement, and operate business information systems, IT Services, and IT infrastructure; and

(b) Plan, manage, and control the projects that perform those activities.

The SDLC process is complementary to other federal IRM processes such as Enterprise Architecture (EA), Capital Planning and Investment Control (CPIC), Information Assurance (IA), Risk Management, and Records Management.4 It does not replace these other processes.

To be effective, the SDLC must define and integrate the project management and systems engineering work activities that are performed by an IT project team – while enabling effective risk management and governance. Project management activities help organizations to plan, perform, monitor, and control projects. System engineering activities help organizations to design, develop, integrate, deploy, and operate IT products and services. Figure 1.2-1 below depicts how the SDLC process relates to other mandated IRM processes.

4 See the NARA IRM Strategic Plan for a more comprehensive description of IRM processes and their mandates.

SDLC.Methodology.docx November 27, 2013 5

Figure 1.2-1. Overview of Information Resources Management (IRM) Processes

The key take-away from this figure is that the IRM processes used to identify business initiatives and manage NARA’s project portfolio (Strategic Planning, CPIC Select, EA), are different than the IRM processes used to develop, deploy, and operate IT products and IT services (SDLC and Project Management). The SDLC process is used to define, plan, and manage work activities that produce the IT products and services that NARA requires.

1.3 Overview of NARA’s SDLC

NARA’s SDLC process is structured to be simple and flexible. The process focuses on achieving meaningful project outcomes, not on prescribing specific, detailed work steps or massive amounts of documentation. However, the process is also intended to ensure that all projects, regardless of their size and complexity, perform adequate planning and analysis prior to making financial and contractual commitments to an IT system or IT service acquisition. For any

SDLC.Methodology.docx November 27, 2013 6 given project, the tasks, their sequencing, and the work products that are produced should be commensurate with the nature of the system being developed and the complexity of the project that implements and deploys that system. It is incumbent upon the business sponsor, project manager, and lead system engineer to determine the best approach for meeting project objectives and ensuring successful business outcomes.

NARA’s SDLC provides a process framework and associated guidance that can be used to make decisions about how best to approach the implementation of an IT product or service, and how to plan and manage the project that will perform the implementation activities. NARA’s SDLC process is predicated upon four basic concepts: (1) SDLC stages, (2) SDLC gate reviews, (3) SDLC activities, and (4) SDLC tailoring.

(1) SDLC Stages represent the level of maturity of a system as it moves through the life cycle from the analysis of business needs and the development of a system concept at the onset, through the design of a system solution, to the development and deployment of the solution, and finally to the ongoing operation and maintenance of the system and its eventual retirement. All systems will progress through these general stages of maturity, regardless of their size and complexity.

(2) SDLC Gate Reviews are prescribed governance checkpoints within the system life cycle that are used to assess the maturity of a system and the readiness of a project to move to the next stage of implementation. Gate reviews are used to validate the outcomes of a project, independent of the project team, and inclusive of the perspectives of all agency stakeholders (e.g., business, CPIC, IA, EA, systems engineering, acquisition, records management, and IT operations). Gates reviews ensure that cost, schedule, business, and technical risks are understood and mitigated throughout the system implementation process. Gate reviews also determine if the system, at each stage of maturity, meets requirements - and can still deliver the expected benefits when needed in accordance with the cost and schedule estimates established by the business case.

(3) SDLC Activities are broad categories of systems engineering tasks that are performed to implement a system. SDLC activities include: (a) business needs analysis; (b) concept development; (c) requirements analysis; (d) design, (e) development; (f) deployment preparation; (g) operations and maintenance; and (h) retirement. These activities can be performed sequentially, iteratively, or concurrently depending upon the nature of the system and the needs of the project.

(4) SDLC Tailoring is a planning activity whereby the project manager and lead systems engineer assess the nature of the system being developed and the overall complexity of the project. Based on this assessment, an appropriate SDLC tailoring plan is developed that defines the tasks and work products that are appropriate to and necessary for successful project performance and system implementation. The tailoring plan is used to vet the proposed approach to system implementation and project management with all agency stakeholders. The tailoring plan supports and influences the project management plan, the work breakdown structure (WBS), and the acquisition plan for the system.

An overview of NARA’s SDLC process is depicted in Figure 1.3-1 below. CPIC phases are noted at the bottom of the figure to show how the various SDLC activities align with OMB’s

SDLC.Methodology.docx November 27, 2013 7 prescribed CPIC reviews. Each of the four SDLC concepts mentioned above is discussed in more detail in the subsequent sections of this document.

Figure 1.3-1. Overview of NARA’s SDLC Process

SDLC.Methodology.docx November 27, 2013 8

1.4 Initiating a Project

The need for systems cannot always be anticipated and planned in conjunction with the agency’s formal budgeting process and EA process. NARA’s SDLC methodology recognizes that system needs can arise from multiple sources and at any time. The SDLC provides a pathway for a notional system idea to be presented and reviewed - and then approved, or rejected if it does not reflect a legitimate business need. This is accomplished by using a simple, two-step process as depicted in the top half of Figure 1.4-1 below. This two-step process constitutes the Business Needs Analysis activity and is how all projects are started.

Figure 1.4-1. Initiating a Project

Figure 1.4-1 shows that the first step of project start-up is for the business sponsor to summarize the business need, validate that no exiting systems can meet that need, and obtain approval from the Architecture Review Board (ARB) to explore the idea in more detail. The second step in the process is to perform a comprehensive business needs analysis, assess the impact of the proposed system on NARA’s EA, and assign a project manager. Based upon the outcome of these two steps, the gate review will determine if it is appropriate to allocate resources to SDLC Concept Development activities. Concept Development activities fully conceptualize the system, develop a comprehensive project plan, develop the business case, and determine the acquisition approach.

SDLC.Methodology.docx November 27, 2013 9

1.5 Reference Documents

The sources identified in Table 1.5-1 below provide general references that are germane to NARA’s SDLC methodology. NARA’s SDLC is based primarily on the methods and concepts presented in the INCOSE Systems Engineering Handbook, which is derived from the ISO/IEC 15288:2008 systems engineering standard, and the corresponding software engineering standard

ISO/IEC 12207:2008.

Table 1.5-1. Reference Documents

Document Description

Clinger-Cohen Act of 1996 The Information Technology Management Reform Act, the Federal Acquisition Reform Act, and other reform legislation became known as the Clinger-Cohen Act (Public Law 104-106, 40 U. S. C. 11315).

Management of Federal Information Resources, OMB Circular A-130 (Nov. 30, 2000)

OMB’s direction to Federal agencies to establish and maintain life cycle processes (among other topics).

ISO/IEC 15288:2008 Systems and software engineering - System life cycle processes

An international standard that provides a generic description of systems engineering lifecycle processes. This standard consolidates information from a number of earlier standards (e.g., IEEE 1220 and EIA 632) into a cohesive systems engineering process framework.

ISO/IEC 12207:2008 Systems and software engineering - Software life cycle processes

An international standard that provides a generic description of software engineering lifecycle processes. From the perspective of ISO/IEC 15288 (and systems engineering in general), software engineering is considered a specialty engineering field like human factors engineering, mass properties engineering, security engineering, reliability and maintainability engineering, environmental engineering, and integrated logistics support.

ISO/IEC TR 24748-1 First Edition 2010-10-01 Systems and software engineering – Life cycle management

- Part 1: Guide for life cycle management

A Technical Report to facilitate the joint usage of the process content of ISO/IEC 15288 and ISO/IEC 12207. The purpose of the report is to help ensure consistency in system concepts and life cycle concepts when the two International Standards are used in combination.

INCOSE Systems Engineering Handbook, Version 3.2.1, January

This handbook elaborates on the generic processes expressed in ISO/IEC15288 and provides practical guidance on how to adapt and use systems engineering processes. The INCOSE handbook provides the basis for NARA’s SDLC.

SDLC.Methodology.docx November 27, 2013 10

Table 1.5-1. Reference Documents

Document Description

Project Management Institute - A Guide to the Project Management Body of Knowledge: (PMBOK Guide)

This handbook provides detailed information on the generic project management processes that are described in the INCOSE Handbook, from the perspective of project management and project control (as opposed to the systems engineering perspective presented by INCOSE).

NIST SP 800-64 Revision 2 – Security Considerations in the System Development Life Cycle

General guidance provided by NIST to assist federal government agencies with integrating essential information technology (IT) security steps into their established IT system development life cycle.

NIST SP 800-30 – Risk Management Guide for Information Technology Systems.

Section 2.2 of this reference provides general guidance for integrating risk management into the SDLC.

SDLC.Methodology.docx November 27, 2013 11

2 SDLC Stages and Gate Reviews

2.1 SDLC Stages

NARA’s SDLC establishes four stages of system implementation: (1) Concept, (2) Design, (3) Build, and (4) Utilization and Support. All systems will progress through these four stages regardless of their size and complexity. It is important to note that an SDLC stage is different than a project phase. SDLC stages represent the level of maturity of a system as it moves through the life cycle. Project phases represent a period of time on a project schedule.

Although it may seem intuitive that system stages and project phases are aligned, this is often not the case. Unfortunately, when project phases get defined at a project’s onset, insufficient information is available to accurately estimate schedules and costs. SDLC stages provide logical breakpoints, called gate reviews, during which schedules, cost estimates, and system specifications can be reviewed and assessed as more detailed information is gathered about the system. Gate reviews are used to ensure that project plans get updated to reflect more accurate estimates based upon actual project progress – and ensure that the system meets requirements and can still be delivered on time and in accordance with its business case. Gate reviews provide management visibility into a project and enable more effective risk management. NARA’s governance boards oversee SDLC gate reviews for IT projects.

It is extremely important not to skip SDLC stages to expedite the project schedule as this invariably leads to increased risk, and often times outright project failure. Figure 2.1-1 below provides an overview of the stages in NARA’s SDLC and identifies the high-level outcomes that are expected at each stage of maturity. Achieving these outcomes demonstrates that the system is mature enough, and the project is sufficiently controlled, to progress to the next stage of implementation.

Figure 2.1-1. Overview of SDLC Stages

2.2 SDLC Gate Reviews

NARA’s SDLC establishes an initial business review in the middle of the Concept stage, and four project gate reviews as depicted in Figure 2.2-1 below. The business review is used only to initiate a project. At this review, notional project ideas are either: (a) approved for full planning and analysis; or (b) rejected if they do not reflect a legitimate business priority. At each of the subsequent project gate reviews: (a) project outcomes are reviewed against the project plan (b);

SDLC.Methodology.docx November 27, 2013 12 the business case is reviewed to ensure that it is still valid; (c) the technical feasibility of the system is assessed; and (d) the overall project receives a thorough risk review. The CPIC phases are noted at the top of Figure 2.2-1 to show how CPIC controls align with the SDLC. Both SDLC and CPIC considerations are addressed at the gate reviews.

Figure 2.2-1. SDLC Gate Reviews

Each of the project gate reviews depicted in Figure 2.2-1 have exit criteria that must be satisfied to demonstrate that the project has successfully completed the current SDLC stage and the system is mature enough to proceed to the next stage. Table 2.2-1 below identifies the criteria for exiting each SDLC gate review, and identifies additional criteria that must be met to enter the subsequent SDLC stage. All gate reviews identified in Figure 2.2-1 are required. In fact, it may be necessary to incorporate additional gate reviews into to a project schedule for larger, more complex projects (e.g., preliminary and detailed design reviews) – or for projects that will perform multiple iterations of SDLC activities (e.g., projects using agile or iterative development approaches). For small systems, very simple projects, or projects using adaptive or concurrent engineering approaches it may be possible to combine gate reviews in some cases. The number and timing of gate reviews should be planned during the Concept Stage and should be tailored to the specific needs of each project. Figure 2.2-2 below depicts some gate review patterns that illustrate how gate reviews can vary for different SDLC approaches. (Note: When an adaptive SDLC approach (e.g., agile) is used by a project, it is essential to perform extensive project planning, and schedule comprehensive reviews of the system’s architecture concept before beginning development activities. Additionally, requirements must be well tracked and managed when using adaptive approaches because they may be quite volatile.)

SDLC.Methodology.docx November 27, 2013 13

Table 2.2-1. SDLC Gate Review Exit Criteria

Gate Review Exit Criteria

Business Needs Analysis Stage Exit / Approval to Plan Project

• Business Needs Analysis reviewed & approved

• Business sponsorship confirmed

• ARB approval to initiate project

• Project Manager assigned

Required to Enter Next Stage

• Resources made available for Concept Development activities

Concept Stage Exit / Approval to Design System

• All Concept Stage work products are completed, reviewed, & approved

• SDLC tailoring approach approved

• System & project concepts developed and documented

• Business case developed and documented

• All risks, comments, and action items are addressed

Required to Enter Next Stage

• Funding made available for Design Stage

• Required Acquisition(s) for Design Stage completed

• ARB approval to design system

Design Stage Exit / Approval to Build System

• All Design Stage work products are completed, reviewed & approved

• Functional specifications documented

• Technical specifications documented

• Requirements traceability verified

• All risks, comments, and action items are addressed

Required for Next Stage

• PMP/WBS for Build Stage approved

• Required Acquisition(s) for Build Stage completed

• Funding made available for Build Stage

• Business case updated and validated

SDLC.Methodology.docx November 27, 2013 14

Table 2.2-1. SDLC Gate Review Exit Criteria

Gate Review Exit Criteria

• Governance Board approval to build system

Build Stage Exit / Approval to Install and Operate System

• All Build Stage work products are completed, reviewed, & approved

• All risks, comments, and action items are addressed

• Delivered system is integrated and verified

• System pilot(s) is validated and accepted

• Rollout preparation is completed

• Authority to rollout & operate is signed

Required to Enter Next Stage

• PMP/WBS for Utilization and Support Stage approved

• Required Acquisition(s) for Utilization and Support Stage completed

• Funding made available for Utilization and Support Stage

• Business Case updated and validated

• Governance Board approval to install & operate system

Utilization and Support Stage Exit / Approval to Dispose of System

• Information Assurance Controls Verified

• Records Safeguarded/Archived

• Project Closeout Report reviewed, signed, and accepted

• System disposal verified

• All risks, comments, and action items are addressed

• Governance Board approval to dispose of system

SDLC.Methodology.docx November 27, 2013 15

Figure 2.2-2. Sample SDLC Gate Review Patterns

2.3 Preparing for SDLC Gate Reviews

The purpose of a gate review is to have the appropriate governance board review the status of the project against the exit criteria for the applicable SDLC stage. Based upon the outcome of the gate review, the governance board determines whether or not the project has satisfied the exit criteria and can proceed to the next SDLC stage. The possible gate review outcomes, as per the judgment of the governance board, and the corresponding governance decisions are identified in Table 2.3-1 below. It is the project manager’s responsibility to plan for and schedule gate reviews as part of the project’s overall project plan and schedule.

Project managers must allow adequate time not only for the actual gate review meeting, but also for any ancillary meetings and work efforts that are necessary to prepare for the gate review.

Project managers should ensure that all work products have been delivered - and reviewed by both the project team and any appropriate stakeholders external to the project. All stakeholder issues, risks, and concerns should be addressed and, ideally, resolved prior to gate reviews. A gate review meeting should be treated as a forum to:

SDLC.Methodology.docx November 27, 2013 16

• Arbitrate issues with stakeholders that cannot be resolved solely by the project team;

• Validate that all risks have been addressed and appropriately mitigated;

• Verify that the project is on schedule and on budget, and the system can still meet requirements and satisfy the objectives established by the business case;

• Ensure that adequate funding and resources are available for the next SDLC stage; and

• Render a final decision as to whether or not the project should continue.

Gate review meetings are not a forum to discuss and resolve internal project issues, or to address the technical details of the system. These types of discussions should occur in project status meetings or in project work sessions.

Table 2.3-1. Gate Review Outcomes and Governance Decisions

Gate Review Outcome Governance Decision

All Criteria Met Proceed to next stage

Criteria Mostly Met Proceed once all risks and action items are addressed

Criteria Not Met Continue with this stage until all criteria are met

Major scope, schedule, or requirements changes are necessary

Return to a prior stage as designated by the governance board

Non-Performing Project Suspend project activity and re-plan project

Unsalvageable Project Terminate project

SDLC.Methodology.docx November 27, 2013 17

3 SDLC Activities SDLC activities are broad categories of technical and project management tasks that get performed by a project team to actually realize a system of interest. NARA’s SDLC establishes eight SDLC activities that are performed to implement a system including: (1) Business Needs Analysis; (2) Concept Development; (3) Requirements Analysis; (4) Design, (5) Development; (6) Deployment Preparation; (7) Operations and Maintenance; and (8) Retirement. SDLC activities are comprised of numerous, discrete tasks that gradually evolve the maturity of a system -thereby achieving the outcomes that are necessary to successfully manage the project and implement the system. Figure 3-1 below identifies the technical and management outcomes expected for each of the eight SDLC activities, and shows how they align to the various stages of system maturity. Table 3-1 below defines the purpose of each SDLC activity and lists its expected outcomes. The discrete tasks and work products that comprise each SDLC activity are discussed in detail in Appendix A.

Project team members having expertise in specific functional areas or technical disciplines perform the SDLC tasks planned for a project. Depending on the type of system being developed, an Integrated Project Team (IPT) may need to be established that includes specialists from a variety of functional areas (e.g., requirements engineering, verification and validation, functional analysis, modeling and simulation, configuration management, and quality assurance)

- and from a variety of engineering disciplines (e.g., software engineering, reliability and maintainability, logistics, safety, survivability, security, and human factors).

Figure 3-1. Overview of SDLC Activities and Main Objectives

SDLC.Methodology.docx November 27, 2013 18

Table 3-1. Purpose and Outcomes of SDLC Activities

Activity Purpose Expected Outcomes

Business Needs Analysis

The purpose the Business Needs Analysis activity is to explore the business need for system capabilities, summarize those needs, analyze them in detail, and vet them with key business stakeholders

• Business Sponsor Identified

• Business Need Summarized

• System Need Validated

• EA Impact Assessed

• Business Needs Summary Document Approved by ARB

• Business Needs Fully Analyzed & Documented

• Project Manager Assigned

Concept Development

The purpose of the Concept Development activity is to: (a) define the overall system concept and the project concept for managing the implementation of the system; and (b) develop a comprehensive business case for acquiring the system.

• System Concept Developed and Documented

• Project Concept Developed and Documented

• EA Conformance Verified

• Business Case Developed and Documented

• Acquisition Approach Determined

Requirements Analysis

The purpose of the Requirements Analysis activity is to develop a functional representation of a system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation.

Requirements analysis should provide a comprehensive functional description of the envisioned system.

• Functional Design Developed

• Functional Requirements Specified

• Non-functional Requirements Specified

• Requirements Traceability Established

• Project Management Documents Updated

Design The purpose of the Design activity is to synthesize a system solution that meets the system requirements.

The design should provide a comprehensive technical description

• Design Trade-off Analyses Completed

• System Design Specified

• Requirements Traceability Established

SDLC.Methodology.docx November 27, 2013 19

Table 3-1. Purpose and Outcomes of SDLC Activities

Activity Purpose Expected Outcomes of the envisioned solution • Project Management Documents Updated

• Business Case Updated and Validated

• Next Stage Acquisition Activities Completed

Development The purpose of the Development activity is to build the system elements that comprise the system solution - in accordance with the design. Development activities transform design specifications into specified hardware, software, procedures, or training elements.

• System Configuration Items (CIs) Built, Verified & Integrated

• CI Specifications Documented

• Project Management Documents Updated

Deployment Preparation

The purpose of the Deployment Preparation activity is to prepare for the installation and rollout of the system. Deployment preparation activities assess the impact of the as-built system elements on the current operating environment, install the system in a pilot environment, validate the system installation, and train and prepare all users, operators, and maintainers to use the system.

• Operations Engineering Completed

• Installation Preparation Completed

• Operations Preparation Completed

• Rollout Preparation Completed

• Training Preparation Completed

• Pilot System(s) Installed/Validated

• Project Management Documents Updated

• Business Case Updated and Validated

• Next Stage Acquisition Activities Completed

• ATO Obtained

Operations and Maintenance

The purpose of the Operations and Maintenance activity is to deploy and use the system in production operations, and sustain the system’s capabilities throughout its useful lifecycle.

• System Rollout Completed

• System Use Monitored and Evaluated

• System Supported and Maintained

• Annual ATO Maintained

Retirement The purpose of the Retirement activity is to end the existence of a system. Retirement deactivates, disassembles, and removes all

• System Elements Disposed Of

• Disposal Documentation Verified

SDLC.Methodology.docx November 27, 2013 20

Table 3-1. Purpose and Outcomes of SDLC Activities

Activity Purpose Expected Outcomes elements of a system from the operating environment. Retirement also ensures that all records, data, media, and removed system elements are disposed of and safeguarded in accordance with applicable laws, regulations, and policies.

Although Figure 3-1 depicts SDLC activities in a manner that follows a sequential, waterfall approach to system implementation, it is important to note that NARA’s SDLC does not prescribe a waterfall methodology. The waterfall outline is presented only to provide a common frame of reference because it is the most widely understood approach to system implementation.

In fact, SDLC activities can be performed sequentially, iteratively, concurrently, or incrementally throughout the four stages of system maturity depending upon the needs of the system. For example, requirements analysis tasks can be performed during the concept stage to identify stakeholder requirements; during the design stage to identify functional and non-functional requirements; during the development stage to refine installation and support requirements; and during the operations and maintenance stage to specify necessary changes in system capabilities.5 As another example, adaptive, non-linear software development methods (e.g., Agile) tend to perform Requirements Analysis, Design, Development, and Deployment Preparation tasks concurrently and iteratively in the context of small, frequent releases of business capabilities.

Figure 3-2 below shows how it is possible to apply all SDLC activities across all life cycle stages as the system matures. Generally, certain SDLC activities tend to be used more heavily in certain life cycle stages (e.g., design activities in the Design Stage), and less heavily in others (e.g., concept development activities in the Utilization and Support Stage). However, all SDLC activities tend to be used to some degree in all life cycle stages, and there is no hard and fast rule regarding how best to sequence SDLC activities.

It is incumbent upon project teams to use plan driven, adaptive, iterative, or concurrent SDLC approaches as applicable to the system they are developing – but the approach that is selected must address all aspects of a system including hardware, software, people, and processes.

Projects are free to tailor SDLC activities into a waterfall, spiral, incremental, evolutionary, concurrent, lean, or agile approach based upon the nature of the system and the needs of the

5 INCOSE identifies seven project processes and eleven technical processes that are applied to varying degrees, throughout the life cycle of a system. NARA’s SDLC methodology accounts for all of the tasks represented by the INCOSE processes in the SDLC activities, but consolidates them, simplifies their organization, and adopts terminology that is more familiar to NARA staff and contractors.

SDLC.Methodology.docx November 27, 2013 21 project. It is also possible to use multiple approaches within the same project, and use a variety of project management guidelines (e.g., PMBOK, CMMi). What is important is to ensure that the desired outcomes are achieved as planned regardless of the implementation approach that is selected. SDLC tailoring is discussed in greater detail in Section 4 of this document.

Figure 3-2. SDLC Activities Applied to SDLC Stages

SDLC.Methodology.docx November 27, 2013 22

4 SDLC Tailoring

4.1 Tailoring Plan

The primary purpose of NARA’s SDLC is to help projects identify and plan work activities that are necessary to achieve successful project outcomes. Every project and system differs in scope, complexity, and risk. This makes it necessary to tailor the SDLC to the specific needs of a project. Tailoring the SDLC is a critical work activity that gets performed during the concept stage of a project. All projects are required to develop a tailoring plan. The tailoring plan is developed by the project manager and the lead systems engineer - and must be approved by the ARB to exit the concept stage of the life cycle.

The tailoring plan identifies critical system engineering and project management activities that must be performed to successfully implement the proposed system. Because the tailoring plan identifies the work activities that must be performed, developing the tailoring plan is a prerequisite for establishing the project work breakdown structure (WBS) and schedule - and for performing project cost analyses. It is also a prerequisite for understanding and managing risk.

4.2 Tailoring Concepts

There are three simple concepts that need to be understood to tailor the SDLC for any given project: (1) SDLC work streams (2) project types; and (3) work product templates.

(1) SDLC work streams are generalized workflow templates for planning and managing projects. These templates identify the tasks that are required to successfully perform broad types of system implementation projects (e.g., custom application development or IT infrastructure upgrade) - and they prescribe gate reviews to enable risk management and effective governance. Because work streams are generalized, they must be adjusted to the needs of individual projects. They are not intended to tie the hands of project managers and system engineers – but they are intended to prescribe the tasks that are necessary to ensure project success when performing a certain type of project. It should be noted that SDLC work streams are not the same thing as generic system implementation approaches (e.g.; waterfall, spiral, incremental, iterative, concurrent, lean, or agile). Work streams can be tailored to use any of these approaches (or combinations thereof) based upon the needs of a project.

(2) Project Type is determined by the nature of the system being developed and the scope of the project. Systems tend to increase in complexity as: (a) the scope of functionality increases; (b) the number and diversity of technical elements increases; (c) the number of system interfaces increases; or (d) as new technologies are introduced. Projects tend to increase in complexity as: (1) the scope of business impact increases; (2) the number and variety of stakeholders increases; (3) the size of the project team increases; (4) specialized information assurance needs are added; or (5) the number of dependencies on other projects and other systems increase. Increased system and project complexity invariably leads to increased project risk.

SDLC.Methodology.docx November 27, 2013 23

(3) Work Product Templates are generalized formats for the deliverables that are produced by a project as it progresses through the life cycle. These templates outline the types of information that are typically contained in certain document types (e.g., requirements specifications, design specifications, concept of operations, use cases, configuration management plans and project management plans) and provide a pre-formatted structure for developing project documents. Work product templates can be modified or combined to meet the need of a given project.

4.3 Tailoring Process

NARA’s SDLC prescribes a five-step process for tailoring the SDLC to project needs, and provides templates, forms, and guidelines to assist project managers with tailoring. The tailoring process allows the tailoring plan to be refined incrementally as more detailed information about the system and the project becomes available. The tailoring process is performed during the SDLC concept stage – but the tailoring plan can be modified as necessary throughout the life cycle. An overview of the tailoring process is depicted in Figure 4.3-1 below. Additional detail about each step in the process is provided in the subsequent sections.

Figure 4.3-1. Overview of the SDLC Tailoring Process

SDLC.Methodology.docx November 27, 2013 24

4.3.1 Determining the Work Stream Type

The first step in SDLC tailoring is to determine the type of system that is being implemented.

Different types of system implementations require that different types of tasks be planned and performed. For example, implementing a very large custom-developed software system is quite a different undertaking than updating the IT infrastructure to support a new communications protocol, or providing a new directory service. NARA’s SDLC pre-defines eight work stream options that support the types of systems typically implemented at NARA. The work streams fall into two main categories: (1) business application work streams; and (2) IT infrastructure service work streams. It is not expected that projects will exactly fit a specific work stream type.

For this reason, the tasks and sequencing described by the various work streams get further refined in subsequent steps of the tailoring process. Table 4.3.1-1 below lists NARA’s eight work stream options and describes the types of system implementations for which they are used.

Projects can simply identify the work stream that most closely describes the type of system being implemented. (Note: The rows in the table are color coded to match the work stream to the corresponding template for that work stream in Appendix B).

Table 4.3.1-1. SDLC Work Streams

Work Stream Description

Business Application Work Streams

New Custom Developed or COTS Application

Used for new systems that: (a) require significant custom development; (b) use modified COTS products to satisfy requirements; or (c) include both custom developed and COTS software elements. Examples include ERA, DAS, ARCIS, and HMS.

New Software as a Service (SaaS) Application

Used for new systems that will be: (a) provisioned external to NARANET by an external service provider; (b) accessed over the Internet using a web browser; and (c) used “as-is” based upon a vendor-defined Service Level Agreement. Examples include SCTS and OAS.

Application Upgrade Used to upgrade the business software of an existing system either to:

(a) add significant new functional capabilities; (b) make significant changes to the underlying database structure, application architecture, or application platform of a COTS product; or (c) dispose of an application. Examples include CMRS and ADRRES.

Application Maintenance Used for routine maintenance, bug fixes, or minor functional enhancements to an existing business application. Examples include OFAS and ENOS updates.

SDLC.Methodology.docx November 27, 2013 25

Table 4.3.1-1. SDLC Work Streams

Work Stream Description

IT Infrastructure Service Work Streams

New IT Infrastructure Capability

Used to provision new IT infrastructure services. Examples include the enterprise wireless deployment and Storage Network Infrastructure (SNI).

New Platform as a Service (PaaS) / Infrastructure as a Service (IaaS) Capability

Used to implement IT infrastructure capabilities that will be: (a) provisioned external to NARANET by an external service provider;

(b) accessed via NARA’s Internet interface; and (c) used predominantly “as-is” based upon a Service Level Agreement (SLA).

Major IT Infrastructure Upgrade

Used to upgrade an existing IT infrastructure service that: (a) adds significant new capabilities; (b) significantly impacts interoperability with other IT infrastructure services; (c) makes significant changes to underlying service technologies; (d) moves in-house infrastructure services to an external service provider; or (e) disposes of an existing IT Infrastructure system or service. Examples include NARANET Server Upgrade (NSU), MPLS migration, and cloud-based email.

IT Infrastructure Refresh Used to upgrade hardware, system software, or network devices that will minimally impact current configuration settings or interoperability with other IT components. Examples include, switch replacements, router upgrades, desktop COTS software updates, or server upgrades that do not affect the application platform.

4.3.2 Determining the Project Type

The second step in SDLC tailoring is to generally characterize the type of project that is being performed. Project type is determined by system complexity and project scope because, ultimately, these two attributes drive cost, schedule, and risk when implementing technology intensive systems. Generally, as a project’s scope increases and a system gets more complex, additional project management and systems engineering work activities are required.

NARA’s SDLC specifies three types of projects: (1) Low Complexity Projects; (2) Medium or High Complexity Projects; and (3) Projects having high information assurance risk. When considering project type, SDLC tasks are additive. This means that as complexity and scope increase, additional work activities must be added to address that scope and complexity. It is not important that projects be classified by some arbitrary rating such as high/medium/low or large/medium/small. What is important is that all necessary systems engineering tasks and project management activities get planned and performed.

SDLC.Methodology.docx November 27, 2013 26

Project managers can determine the type of project that they are performing by reviewing the key attributes listed for each type of project in Table 4.3.2-1 below. Typically, projects will not exhibit all of the key attributes listed for a project type. In fact, they might have attributes from all three types of projects. Projects managers should look through the key attributes listed for the three project types and choose the project type that best characterizes the specific project they are performing. Later in the tailoring process there is ample opportunity to fine-tune the systems engineering tasks and project management activities that are needed in a project plan.

Table 4.3.2-1. SDLC Project Types

Type of Project Key Attributes

Low Complexity Project • The schedule to achieve Full Operating Capability (FOC) is less than 12 months.

• FOC will be implemented by a single-phase project.

• Interfaces to other systems are not required, or are simple and easy to accommodate.

• The impact to NARANET is well understood, and is easily accommodated.

• Requirements are well understood, or can be elicited and verified in a short timeframe.

• Minimal software development or data conversion is required.

• Solutions are generally available off-the-shelf or as a service.

• The system being developed is isolated to a single business function or business office.

• Expertise across many business or technical disciplines is not required.

• O&M costs and impacts are well understood and easily accommodated.

• Acquisition requirements are minimal and easy to define.

• There would be minimal business impact if the project fails.

Medium or High Complexity Project (Projects of medium and high complexity have the same basic attributes. The complexity of a project typically increases as the complexity of the system increases, and the scope of the project expands in terms of capabilities provided, schedule

• The schedule to achieve Full Operating Capability (FOC) extends beyond 12 months.

• System capabilities will be implemented by multiple phase projects or in increments.

• Interfaces with other systems are required.

• The system introduces significant impacts to NARANET and IT operations.

• Software development and/or data conversion is required.

SDLC.Methodology.docx November 27, 2013 27

Table 4.3.2-1. SDLC Project Types

Type of Project Key Attributes duration, resource needs, integration difficulty, and business/technical impact

– all of which tend to increase cost and risk.)

• Requirements are not well understood at the onset of the project.

• Expertise across several business process areas or technical disciplines is required.

• New technologies and/or new business processes are being introduced.

• Prototyping and/or proof-of-concept efforts may be necessary.

• Significant acquisition support is required across several system life cycle stages.

• There could be significant impact to customer service, business performance commitments, or business mission execution if the project fails.

High Information Assurance Risk Project

• Handles or stores classified information.

• Handles or stores PII data.

• Handles or stores restricted access data (e.g., Title -13, HIPAA).

• Handles or stores permanent archival records or their associated metadata.

• Handles or stores financial information.

4.3.3 Tailoring SDLC Work Stream Tasks

The third step in SDLC tailoring - tailoring SDLC work stream tasks - is the most involved and the most important. This is the step that determines what specific tasks need to be performed -and in what order - to actually implement the system.

Once the project manager has determined the work stream type and project type, the lead systems engineer can be engaged to assist with SDLC work stream tailoring. Each SDLC work stream has a pre-populated template that identifies the SDLC tasks that need to be performed, and associates those tasks with the appropriate SDLC stages based upon the general characteristics of the work stream type. Additional tasks are identified for high complexity projects and projects having high information assurance risk. Project teams should consider the perspectives of all system stakeholders when tailoring the SDLC work stream tasks. Appendix D highlights the particular SDLC tasks that address key NARA stakeholder perspectives including CPIC, Data Administration, Security, Records Management, and IT Operations.

The project manager and lead system engineer can add tasks, remove tasks, or rearrange the sequencing of tasks based upon the specific needs of the project they are performing (simply by redlining the template). However, sufficient justification should be provided when removing

SDLC.Methodology.docx November 27, 2013 28 tasks. SDLC work stream templates are provided in Appendix B and color-coded according to the work stream descriptions in Table 4.3.1-1 above.

When planning large or complex projects, it may be necessary to iterate SDLC activities, re-arrange gate reviews, or add additional gate reviews to support incremental, adaptive, or concurrent approaches to system implementation. The work stream templates can be adjusted to support an iterative or adaptive approach simply by using multiple copies of the template and tailoring each copy to a specific a named increment of the system.

4.3.4 Aligning Work Products to Expected Outcomes

The fourth step in the tailoring process aligns the tasks that must be performed with the outcomes that are required at the various gate reviews – and identifies the work products that will be developed to achieve those outcomes. This step in SDLC tailoring provides the basis for developing the project plan and work breakdown structure, scheduling gate reviews, determining resource needs, estimating the costs of the project, assessing risks, and developing the overall business case.

Once the project manager and the lead system engineer have tailored the SDLC work stream and identified the tasks that need to be performed, they can determine what specific work products need to be developed. Section 3 above provides an overview of the various SDLC activities (e.g., concept development, requirements analysis, and design) and lists the outcomes expected for each activity.