iTRAK Attachment D - Division of Information Systems Final.pdf

Attachment D:

Division of Information Systems

(DIS) Systems Development Lifecycle (SDLC) Guide

March 31, 2011 Version 1.1

Prepared for:

NATIONAL SCIENCE FOUNDATION

DIVISION OF INFORMATION SYSTEMS

4201 Wilson Blvd.

Arlington, VA 22330

NATIONAL SCIENCE FOUNDATION DIS SDLC Guide i

Revision History

Rev. Date Author Reason for Changes

1.0 02/04/11 CIP Team Initial Draft

1.1 03/31/11 CIP Team Removed applications footnote on Figure 2.

i

Table of Contents

1. Overview

1.1 Introduction to This Guide

1.2 Background

1.3 SDLC Phases

2. Reviews

2.1 Artifact Reviews

2.2 Management Gate Reviews

3. SDLC Activities

3.1 Planning & Initiation

3.2 Requirements and Analysis Phase

3.3 Design Phase

3.4 Development Phase

3.5 Test Phase

3.6 Deployment Phase

3.7 Project Closeout Phase

4. Appendix A: SDLC Artifacts by Phase and Required Reviews

1. Overview The SDLC defined here is the system development methodology of the National Science Foundation (NSF) Division of Information Systems (DIS). It is based on a waterfall engineering process that describes who does what, when, and how in a system development and deployment project. It defines the SDLC in terms of phases, deliverables and artifacts. The SDLC is based on guidance from the NSF DIS Deputy Division Director and Branch Chiefs.

The purpose of an SDLC methodology is to provide IT Project Managers with the tools to help ensure successful implementation of systems that satisfy NSF strategic and business objectives. The documentation provides a mechanism to ensure that executive leadership, functional managers and users sign-off on the requirements and implementation of the system. The process provides NSF managers and the Project Manager with the visibility of design, development, and implementation status needed to ensure delivery on time and within budget.

1.1 Introduction to This Guide

This guide intends to help you understand the NSF DIS SDLC Process to follow when initiating and deploying systems/software at the NSF. This guide contains an overview of the SDLC process, high level activities and deliverables in each lifecycle phase, and instructions for how to tailor the SDLC process to fit your project’s needs.

After reading this guide, you will be able to:

Understand NSF DIS’ SDLC process, Tailor the SDLC process to fit your project’s needs, Find and download SDLC templates and procedures.

1.2 Background

The National Science Foundation spends millions of dollars each year on the acquisition, design, development, implementation, and maintenance of systems vital to mission programs and administrative functions. The need to plan for and develop safe, secure, and reliable system solutions is heightened by an increasing dependence on technology to provide services, develop products, administer programs, and perform management functions.

There is also a need to ensure privacy and security when developing information systems, to establish uniform privacy and protection practices, and to develop acceptable implementation strategies for these practices.

The SDLC methodology is designed to satisfy these needs by establishing procedures, and practices governing the initiation, requirements, design, development, testing, deployment, operation, maintenance, enhancement, and eventual retirement of automated information systems. This SDLC methodology shall be used for all Major Development Projects which have been defined as meeting one or more of the following criteria:

(1) The estimated total cost of full lifecycle activities equals or exceeds $500K;

(2) The project is undertaken to support a critical business function associated with the grants management lifecycle or legislative mandates; or

(3) The DIS Deputy Division Director determines that the project requires the special attention and consideration given to a major information technology development project.

For upgrades or enhancements not designated as Major Development Projects, project teams are strongly encouraged to tailor and use the planning, requirements analysis, design, development, and testing documentation tools provided by the SDLC to support sound project management practices.

1.3 SDLC Phases

The NSF SDLC describes important elements of software development in a common and consistent way. This process is broken down into seven phases. The NSF DIS SDLC provides a standard approach that results in the production of well documented, quality software.

NATIONAL SCIENCE FOUNDATION

Figure

1.3.1 Tailoring the SDLC

The concept of roadmaps was introduced of roadmap adopted will depend on the type of change will require more assets and more planning for risk mitigation than a release made up of defects only. The SDLC has defined five roadmaps for projects to select fr roadmaps are:

1. New Development

2. Major Enhancements

3. Enhancements and Defects

4. Defects

5. Emergency

The roadmaps listed above are to be used with the Roadmap Matrix. This matrix shows which assets should be created or updated for each phase of the SDLC. The Roadmap Matrix also shows whom is responsible for creating/updating the assets, the review type that should be conducted for the asset, organizations that may participate in some of the reviews (QA, TaSS and NSF Release Engineers) and i Operating Procedure (SOP) exists to provide guidance in developing the required asset for the selected Roadmap.

A roadmap may be tailored to meet the needs of a project.

NATIONAL SCIENCE FOUNDATION

gure 1: NSF DIS SDLC Phases & Key Deliverables was introduced to help projects tailor the SDLC to meet their requirements. The type depend on the type of change being implemented. Major Enhancements more assets and more planning for risk mitigation than a release made up of defects only. The SDLC has defined five roadmaps for projects to select from during the development life c

The roadmaps listed above are to be used with the Roadmap Matrix. This matrix shows which assets should be se of the SDLC. The Roadmap Matrix also shows whom is responsible for creating/updating the assets, the review type that should be conducted for the asset, organizations that may participate in some of the reviews (QA, TaSS and NSF Release Engineers) and if a procedure or Standard Operating Procedure (SOP) exists to provide guidance in developing the required asset for the selected be tailored to meet the needs of a project. If a required artifact is not needed for a particular

DIS SDLC Guide to meet their requirements. The type implemented. Major Enhancements, for example, more assets and more planning for risk mitigation than a release made up of defects only. The DIS om during the development life cycle. The five

The roadmaps listed above are to be used with the Roadmap Matrix. This matrix shows which assets should be se of the SDLC. The Roadmap Matrix also shows whom is responsible for creating/updating the assets, the review type that should be conducted for the asset, organizations that may f a procedure or Standard

Operating Procedure (SOP) exists to provide guidance in developing the required asset for the selected is not needed for a particular project, justification must be provided in the Project Charter or Release Summary Document (RSD). The justification for not creating or updating an asset must be provided in the beginning of the project or after the project starts. If in the middle of the development life cycle a project determines that it will not be able to develop a required artifact for the roadmap selected, the Project Charter or RSD must be updated to reflect this change and approved.

A more detailed description of the roadmaps can be found in the following sections.

1.3.1.1 New Development

A New Development project is defined as being a brand new project that has never released its code to production. The purpose of a new development project is to create/deliver a new Information Technology (IT) solution to the production environment, for the first time, to meet a business need or solve a business problem.

An example of a New Development project is launching a system for the first time.

1.3.1.2 Major Enhancements

The Major Enhancements roadmap typically consists of enhancement Change Requests (CRs) only and it is for Operations and Maintenance (O&M) projects. The Enhancements roadmap is for projects that already have code in production. An Enhancement may be implemented to modernize, enhance or maintain an existing application. Major Enhancements may also include adding new modules to an existing application. An example of a Major Enhancement is the enhancement of the eJacket application to provide program staff with the ability to process a proposal from end-to-end in one application and in a paperless process (eJacket DD Concur).

1.3.1.3 Enhancements and Defects

The Enhancements and Defects roadmap is geared towards releases consisting of CRs that are minor enhancements and defect fixes. This roadmap differs from the Enhancements only roadmap because it also includes defects and the enhancements are on a smaller scale. Major Enhancements should not follow this roadmap. Examples of minor enhancements include improvements to the user interface, adding security related features to online applications, adding functionality to calculate stipends, etc.

1.3.1.4 Defects

The Defects roadmap is made up of defects only. A defect is defined as anything that adversely impacts the expected functionality of an application to the user, differs from the requirements, does not function as designed, or otherwise reduces the quality of an application that is in production. Defects fall under Corrective Maintenance which means the repair of identified faults or defects due to design, logic, or coding errors.

1.3.1.5 Emergencies

The objective of the Emergencies roadmap is to address critical outages or loss of major functionality in an application within a short timeframe. This loss of major functionality in an application is caused by a defect and the highest priority becomes restoring the application to a fully operational state in as short of time possible.

Any new functionality is not considered an emergency; therefore, all emergency requests are defects and not enhancements.

An expedited CR process is used to address emergency defects. A request to fix an emergency must be approved. The fix to address the defect will be put into production as soon as it is properly tested. An update of the assets related to fixing the defect is performed after the fix has been implemented in the production environment. Approved emergency change requests allow a production deployment before all the supporting documentation is completed in order to minimize downtime and reduce impacts to application users. For example, the business analyst may update the requirements documentation after the production release.

1.3.2 Certification & Accreditation Criteria

OMB A-130 defines a major application as an application that requires special attention to security due to the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application. NSF categorizes its major applications as Low and Moderate. Currently, NSF does not have High Impact applications in its system inventory. This categorization is defined in FIPS-199, Standards for Security Categorization of Federal Information and Information Systems.

The following criteria are used as guidance to determine if an application is a major application subject to management review:

The application performs financial transactions.

The application functions in direct support of the NSF mission.

The impact of the loss of system information to the NSF would be:

Moderate if the application’s confidentiality, availability and integrity were compromised. Moderate Impact means the data’s unauthorized disclosure would have a serious adverse effect on the NSF’s reputation or interest. A serious adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: (i) cause a significant degradation in mission capability; (ii) result in significant damage to organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to individuals that does not involve loss of life or serious life threatening injuries.

Low if the application data’s confidentiality, availability and integrity were compromised. In this situation, a Low Impact means the loss of the data’s confidentiality, integrity, or availability could be expected to have a limited adverse effect on NSF. A limited adverse effect means (i) a degradation in mission capability; (ii) result in minor damage to organizational assets; (iii) result in minor financial loss; or (iv) result in minor harm to individuals.

The application could continue to operate at a remote location should the application’s processing environment at NSF become inoperable. NSF major applications are part of the NSF annual Service Recovery testing.

NIST Special Publication 800-37 defines a minor application as an application, other than a major application, that requires attention to security due to the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application. NSF’s minor applications inherit the security controls and protection measures of the NSF Network and Central Computer Facility (CCF). The NSF Network and CCF is certified and accredited every three years using NIST SP 800-53, Recommended Security Controls for Federal Information Systems and Organizations, security controls. NSF reviews the applications technical security controls during the years a C&A is not required.

2. Reviews

2.1 Artifact Reviews

Each artifact should go through a review process prior to being approved. Reviews include project team peer reviews, quality assurance reviews, and reviews with various NSF stakeholders. Peer reviews are an important part of the SDLC process and can save a significant amount of effort and cost when deficiencies are caught early in the lifecycle when they are the least expensive to fix.

Appendix A lists the reviews required for each artifact by lifecycle phase prior to the management gate reviews.

2.2 Management Gate Reviews

Management Gate Reviews are held at various points throughout the SDLC to ensure compliance with the NSF DIS SDLC policies and procedures and to ensure that the project is on time, within scope, and within budget.

The figure below outlines the major management gate reviews, the contents to be reviewed, and the approvals required in order to proceed to the next phase. The project teams will determine in the initiation phase and agree with DIS leadership which gate reviews are required for the project.

Figure 2: NSF DIS Management Gate Reviews

* Business Owner(s) are defined on a per project basis Note: Refer to the CIP Roadmap Matrix for reviews/approvals required on detailed artifacts prior to the Management Gate Review

Gate Gate Review Package Contents Gate Review Approvals Required

Project Initiation Review

Requirements Review

Design Review

Applications Architecture Operations Business Owner(s)*

Management Briefing of Requirements

(Including Communications Guidance (Mgt/Technical)

System Requirements Specification

Technical Implementation Strategy

Management Briefing of Design

High Level Design

System Design Document

High Level Communications Strategy / Roll Out Plan

Test Approach Review

Management Briefing of Test Strategy / Approach

Requirements Traceability Matrix

Detailed Communications Plan

Pre-Deployment Review

Readiness Review Briefing

Key Communications Materials (Promotional/Training)

Project Concept Briefing

High Level Project Schedule

Budget for Requirements Phase

FinancialStructure (Provided by DIS PMO)

Test Results Review

Management Briefing of Test Results

Security Testing Results

3. SDLC Activities

The following sections specify the purpose, the sequence of activities and tasks to be initiated and completed within the SDLC along with the inputs, outputs, and tools available to support each task.

3.1 Planning & Initiation

3.1.1 Purpose

The purpose of the Initiation Phase is to identify and define an opportunity to improve business operations for the organization. A plan is developed that documents the approach to be used and includes a discussion of methods, tools, tasks, resources, project schedules, and user input. Personnel assignments, costs, project schedule, and target dates are established.

3.1.2 Certification & Accreditation (C&A) Activities (If Major Application)

Input and Review of Project Concept Briefing

3.1.3 Required Deliverables

Project Concept Briefing Project Charter Project Management Plan High Level Project Schedule Budget for Requirements Phase

3.1.4 Other Artifacts

Concept of Operations Risk Management Plan

3.1.5 Process Flow

3.1.6 Planning & Initiation Phase Process

PI-01 Submit Request for Decision on Project Categorization

Responsible Party

Federal Project Lead

Input Project idea or concept

Description Federal Project Lead requests a decision from DIS Senior Leadership as to the proper categorization for a new project or initiative.

Tools Project Categorization Guidelines

Output Request submitted to DIS Senior Leadership

Ta

SS

N

SF

Pr oj ec t

Le ad

DI

S

Se cu rit y

Te am

Q ua lit y

As su ra nc e Pr oj ec tT ea m

DI

S Se ni or

Le ad er sh ip

Bu sin es sO w ne rs

PI-02 New Development or Major Enhancement Project?

Responsible Party

DIS Senior Leadership

Input Request for Decision on Project Categorization

Description DIS Senior Leadership reviews the recommendation for the project’s categorization. If DIS Senior Leadership categorizes the project as new development or major enhancement, then the project initiates the planning budget process. If the project is not categorized as new development or major enhancement, then the team will follow the Maintenance release process for implementing the change.

Tools Project Categorization Guidelines

Output Decision on Project Categorization

PI-03 Obtain Approval for Planning Budget from DIS PMO

Responsible Party

Federal Project Lead

Input Planning Budget Request

Description Federal Project Lead develops a Rough Order of Magnitude for completing the planning phase to include the effort for developing the Project Concept Briefing and supporting the gate review process. Once the planning budget is authorized, the team will begin project concept activities.

Tools N/A

Output Approval from DIS PMO

PI-04 Provide Security Input

Responsible Party

DIS Security Team

Input Security Guidelines, Policies, Procedures

Description The DIS Security Team and project team will work together to assess the security needs and future security team involvement based on the initial project concept. The DIS Security Team will use NSF’s security guidelines, policies, and procedures in order to evaluate whether a Certification and Accreditation (C&A) is required for the project.

Tools N/A

Output Security Team input for the Concept Briefing

PI-05 Develop Project Concept, High Level Schedule, Budget

Responsible Party

Project Team

Input NSF and Industry information

Description The following steps should be taken to complete this process step:

1. Gather NSF and industry information about the project idea/concept.

Research similar existing projects and discuss potential options with subject matter experts.

2. Identify staff members to support the project concept/proposal process and identify sponsors.

3. Review potential approaches for performing the scope of work.

4. Perform initial project estimation for cost, effort, and size of the project.

Document the basis of estimate.

5. Identify and document any project risks.

6. Determine Earned Value Management (EVM) requirements.

Tools Risk Management Procedure

Risk Management Template

OMB Risk Categories Reference Guide

EVM Procedural Guidance

Project Schedule Formulation Procedure

Project Schedule Template

Output Project Concept, High Level Schedule, Budget for Requirements Phase, Risks

PI-06 Prepare the Project Concept Briefing

Responsible Party

Project Team

Input Results from Planning Activities

Description Draft the Project Concept Briefing based on results from planning activities

Tools Project Concept Briefing Template

Output Project Concept Briefing

PI-07 Peer Review

Responsible Party

Project Team

Input Project Concept Briefing

Description Perform project team peer review of the Project Concept Briefing. The peer review should include cross team resources to verify impacts across the various applications.

Tools Peer Review Summary Report Template

Output Peer Review Summary Report

PI-08 Quality Assurance Review

Responsible Party

Quality Assurance Team

Input Project Concept Briefing

Description Perform quality assurance review of the Project Concept Briefing

Tools Quality Assurance Review Criteria

Output Quality Assurance Findings

PI-09 NSF Project Lead Review

Responsible Party

NSF Project Lead

Input Project Concept Briefing

Description Perform NSF Project Lead review of the Project Concept Briefing

Output Comments/Feedback on Project Concept Briefing

PI-10 TaSS Review

Responsible Party

TaSS

Input Project Concept Briefing

Description Perform TaSS review of the Project Concept Briefing. The TaSS group will identify potential re-use of existing services, provide options as necessary, identify bottlenecks with the proposed concept and also assess future involvement of TaSS during project execution.

Tools N/A

Output Comments/Feedback on Project Concept Briefing

PI-11 Security Review

Responsible Party

DIS Security Team

Input Project Concept Briefing

Description The DIS Security Team will conduct a final review of the Project Concept Briefing to verify and update the security content resulting from any changes since initial input

Tools N/A

Output Comments/Feedback on Project Concept Briefing

PI-12 Prepare Management Gate Review Package

Responsible Party

Project Team

Input Management Gate Review Package Materials

Description The Project Team prepares a package to be reviewed with the Gate Review attendees which includes the Project Concept Briefing, High Level Project Schedule, and the Budget for Requirements Phase. The project team coordinates with the DIS PMO to provide the financial structure which outlines how the project will be funded and tracked from a financial perspective.

Output Management Gate Review Package

PI-13 Conduct Planning and Initiation Management Gate Review

Responsible Party

DIS Senior Leadership / Business Owner

Input Management Gate Review Package

Description The Project Team distributes the Gate Review package to the attendees in advance of the meeting. A meeting is conducted with the DIS Applications Lead, Architect, Operations, and Business Owner(s) to walk through the Project Concept Briefing and the supporting gate review materials. The Project Team captures any key decisions or actions during the review meeting. The Gate Review process can also occur electronically via email if determined that an in person meeting is not necessary.

Tools N/A

Output Key Decisions and Actions

PI-14 Project Concept Approved?

Responsible Party

DIS Senior Leadership / Business Owner(s)

Input Management Gate Review Package

Key Decisions and Actions from Management Gate Review Meeting

Description DIS Senior leadership and the Business Owner(s) determine whether the project concept is approved to move forward with the project start-up activities and the requirements phase.

If modifications to the materials are requested, then the Project Team makes the necessary modifications and either conducts another in person review or conduct the review electronically.

If the project concept is not approved, then the Project Team will not move forward with the project start up activities.

Output Decision on Project Concept

PI-15 Obtain Approval for Project Concept, High Level Schedule, Requirements Budget

Responsible Party

DIS Senior Leadership / Business Owner(s)

Input Project Concept Decision

Description DIS Senior leadership and the Business Owner(s) provide approval to the Project Team to move forward with the project start-up activities and the requirements phase.

Tools N/A

Output Approval to proceed

PI-16 Conduct Kick Off Meeting

Responsible Party

Project Team

Input Project Concept Briefing, Draft Project Management Plan

Description Project team conducts a kick off meeting with key stakeholders to discuss project scope, roles/responsibilities, timelines, etc.

Tools Kick Off Briefing Template

Project Management Plan Template

Output Shared understanding of roles/responsibilities, scope, timelines, etc

PI-17 Prepare Concept of Operations

Responsible Party

Project Team

Input Approved Project Concept Briefing

Description The Project Team prepares the Concept of Operations document, if applicable.

Once prepared, the document can begin the review process starting with peer review.

Tools Concept of Operations Template

Concept of Operations Review Procedure

Output Concept of Operations

PI-18 Prepare the Project Charter

Responsible Party

Project Team

Input Approved Project Concept Briefing

Description The Project Team prepares the Project Charter document. Once prepared, the document can begin the review process starting with peer review.

Tools Project Charter Template

Output Project Charter

PI-19 Prepare the Project Management Plan

Responsible Party

Project Team

Input Approved Project Concept Briefing

Description The Project Team prepares the Project Management Plan document. Once prepared, the document can begin the review process starting with peer review.

Tools Project Management Plan Template

Output Project Management Plan

PI-20 Peer Review

Responsible Party

Project Team

Input Concept of Operations / Project Charter / Project Management Plan

Description Perform project team peer review of the artifact

Tools Peer Review Summary Report Template

Output Peer Review Summary Report

PI-21 Quality Assurance Review

Responsible Party

Quality Assurance Team

Input Concept of Operations / Project Charter / Project Management Plan

Description Perform quality assurance review of the artifact

Tools Quality Assurance Review Criteria

Output Quality Assurance Findings

PI-22 NSF Project Lead Review

Responsible Party

NSF Project Lead

Input Concept of Operations / Project Charter / Project Management Plan

Description Perform NSF Project Lead review of the artifact

Output Comments/Feedback on Project Concept Briefing

3.2 Requirements and Analysis Phase

3.2.1 Purpose

The Requirements phase focuses on what the system will do in an effort that views all stakeholders, including sponsors and potential users, as important sources of information. During this phase you will:

Develop a high-level understanding of the stakeholders needs

Define the detailed functional and non-functional requirements of the target process or system

Provide an initial mapping of requirements for use in the design, development and testing lifecycles

3.2.2 Certification & Accreditation (C&A) Activities (If Major Application)

Conduct Preliminary Security Risk Assessment

Information Categorization and Sensitivity Assessment

Privacy Impact Assessment

3.2.3 Required Deliverables

System Requirements Specification

Requirements Traceability Matrix

3.2.4 Other Artifacts

Business Requirements

Wire Frames

Other Supporting Requirements Documentation

Communications Guidelines, Strategy, Plan

3.2.5 Process Flow

3.2.6 Requirements and Analysis Phase Process Details

RA-01 Solicit Detailed Functional and Non-Functional Requirements

Responsible Party

Project Team

Input Project Concept Briefing, Concept of Operations, Stakeholder Input

Description Work with stakeholders to elicit needs, constraints, functional and non-functional requirements. Non-Functional Requirements such as security, performance, infrastructure and architecture, environment, flexibility and expansion, portability, maintainability and system administration requirements are typically gathered by meeting with subject matter experts within DIS and are gathered by the Technical Lead.

Use requirements development methods, such as storyboarding and use cases, to begin development of requirements.

Tools Requirements Standard Operating Procedure (SOP)

Output Functional Requirements, Non-Functional Requirements

NSF DIS Requirements Analysis Phase Process Flow

RA-16

Conduct Peer

Review

RA-18

Conduct NSF

Review

RA-12

Conduct

Requirements Gate Review

RA-07

Conduct Peer

Review

RA-15

Develop

Requirements Traceability Matrix

RA-06

Develop the System

Requirements Specification

RA-19

Baseline RTM

RA-09

Conduct NSF Lead Review

RA-01

Solicit Detailed Functional &

Non-Functional Requirements

RA-08

Conduct Quality

Assurance Review

START

RA-10

Baseline

SRS

END

RA-03

Determine Security

Requirements

RA-14

Obtain Approval on

Requirements, Budget for Design thru

Implementation

RA-04

Conduct Preliminary

Security Risk Assessment

Information Categorization and Sensitivity

Assessment

Privacy Impact Assessment

System Requirements Specification

RA-17

Conduct Quality

Assurance Review

RA-11

Prepare

Management Gate Review Package

RA-13

Reqts

Approved?

Yes

Requirements Traceability

Matrix

RA-02

Develop Business Reqts and

Wireframes and Validate with Business Owners

RA-05

Work with Project Team to Develop Communications Guidelines, Strategy, Plan

No, Modifications

Required

RA-02 Develop Business Requirements / Wireframes and Validate with Business Owner(s)

Responsible Party

Project Team

Input Project Concept Briefing, Concept of Operations, Stakeholder Input

Description Work with stakeholders to document business requirements and develop wireframes, if applicable.

Tools Requirements Standard Operating Procedure (SOP)

Output Business Requirements, Wireframes

RA-03 Determine Security Requirements

Responsible Party

DIS Security Team

Input Project Concept Briefing, Concept of Operations, Functional/Non-Functional Requirements

Description Meet with the DIS IT Security Team to determine any and all security requirements. Analyze security requirements within the system security environment to include enterprise information security policy and enterprise security architecture.

Tools NSF Baseline Security Requirements, NIST Guidance

Output System Security Requirements

RA-04 Conduct Preliminary Security Risk Assessment

Responsible Party

DIS Security Team

Input Project Concept Briefing, Concept of Operations, Functional Requirements, Non- Functional Requirements

Description The DIS Security Team works with the Project Team to conduct a preliminary security risk assessment to establish an initial description of the basic security needs of the system. This assessment includes the Information Categorization and Sensitivity Assessment (ICSA). The DIS Security Team reviews the ICSA and determines if a Privacy Impact Assessment (PIA) is needed. If so, the Project Team creates the PIA and reviews it with the DIS Security Team.

Tools Information Categorization and Sensitivity Assessment Template

Privacy Impact Assessment Template

Output Information Categorization and Sensitivity Assessment

Privacy Impact Assessment

RA-05 Work with Project Team to Develop Communications Guidelines, Strategy, and Plan

Responsible Party

Communications Team

Input Project Concept Briefing, Functional Requirements

Description The Communications Team works with the Project Team to understand the project concept and high level requirements. The Communications Team elicits input from the project stakeholders and DIS Senior Management to develop an initial set of communications guidelines, a high level communications strategy and plan.

Output Communications guidelines, High Level Communications Strategy and Plan

RA-06 Develop the System Requirements Specification

Responsible Party

Project Team

Input Business Requirements, Wireframes, Functional Requirements, Non-Functional Requirements

Description The Project Team prepares the System Requirements Specification Document, including security requirements.

Tools System Requirements Specification Template

Output System Requirements Specification

RA-07 Peer Review

Responsible Party

Project Team

Input System Requirements Specification

Description Perform project team peer review of the System Requirements Specification

Tools Peer Review Summary Report Template

Output Peer Review Summary Report

RA-08 Quality Assurance Review

Responsible Party

Quality Assurance Team

Input System Requirements Specification

Description Perform quality assurance review of the System Requirements Specification

Tools Quality Assurance Review Criteria

Output Quality Assurance Findings

RA-09 Conduct NSF Lead Review

Responsible Party

NSF Project Lead

Input System Requirements Specification

Description Perform NSF Project Lead review of the System Requirements Specification

Tools N/A

Output Comments/Feedback on System Requirements Specification

RA-10 Baseline SRS

Responsible Party

Project Team

Input System Requirements Specification

Description Using the project’s Software Configuration Management Plan, baseline the project’s System Requirements Specification

Tools Software Configuration Management Plan

Output Baseline System Requirements Specification

RA-11 Prepare Management Gate Review Package

Responsible Party

Project Team

Input Management Gate Review Package Materials

Description The Project Team prepares a package to be reviewed with the Gate Review attendees which includes the Management Briefing of Requirements, the System Requirements Specification, and the Technical Implementation Strategy (e.g.

pilot, beta release).

Output Management Gate Review Package

RA-12 Conduct Requirements Gate Review

Responsible Party

DIS Senior Leadership / Business Owner

Input Management Gate Review Package

Description The Project Team distributes the Gate Review package to the attendees in advance of the meeting. A meeting is conducted with the DIS Applications Lead, Architect, Operations, and Business Owner(s) to walk through the Requirements Briefing and the supporting gate review materials. The Project Team captures any key decisions or actions during the review meeting. The Gate Review process can also occur electronically via email if determined that an in person meeting is not necessary.

Tools N/A

Output Key Decisions and Actions

RA-13 Requirements Approved?

Responsible Party

DIS Senior Leadership / Business Owner(s)

Input Management Gate Review Package

Key Decisions and Actions from Management Gate Review Meeting

Description DIS Senior leadership and the Business Owner(s) determine whether the project requirements are approved and the project team can move forward with the design phase.

If modifications to the requirements are requested, then the Project Team makes the necessary modifications and either conducts another in person review or conduct the review electronically.

Output Decision on Project Requirements

RA-14 Obtain Approval for Requirements and Budget for Design Through Implementation

Responsible Party

DIS Senior Leadership / Business Owner(s)

Input Decision on Project Requirements

Description DIS Senior leadership and the Business Owner(s) provide approval to the Project Team to move forward with the design phase.

Tools N/A

Output Approval to proceed

RA-15 Develop Requirements Traceability Matrix

Responsible Party

Project Team

Input Baseline System Requirements Specification

Description The Project Team customizes/tailors the Requirements Traceability Matrix to fit the needs of the project. All required information must be pulled from the project’s approved SRS.

Tools Requirements Traceability Matrix Template

Output Requirements Traceability Matrix

RA-16 Conduct Peer Review

Responsible Party

Project Team

Input Requirements Traceability Matrix

Description Perform project team peer review of the Requirements Traceability Matrix

Tools Peer Review Summary Report Template

Output Peer Review Summary Report

RA-17 Conduct Quality Assurance Review

Responsible Party

Quality Assurance Team

Input Requirements Traceability Matrix

Description Perform quality assurance review of the Requirements Traceability Matrix

Tools Quality Assurance Review Criteria

Output Quality Assurance Findings

RA-18 Conduct NSF Review

Responsible Party

NSF Project Lead

Input Requirements Traceability Matrix

Description Perform NSF Project Lead review of the Requirements Traceability Matrix

Tools N/A

Output Comments/Feedback on Requirements Traceability Matrix

RA-19 Baseline RTM

Responsible Party

Project Team

Input Requirements Traceability Matrix

Description Using the project’s Software Configuration Management Plan, baseline the project’s Requirements Traceability Matrix

Tools Software Configuration Management Plan

Output Baseline Requirements Traceability Matrix

3.3 Design Phase

3.3.1 Purpose

The Design phase focus defining the target architecture and application level design. The High Level Design defines the architecture components including the system reference architecture and deployment design. The system design document further elaborates on the architecture as well has the detailed system design including the class diagrams, sequence diagrams, and UI design. Additionally, the system design defines the data architecture including the logical and physical data models and the data dictionary.

3.3.2 Certification & Accreditation (C&A) (If Major Application)

System Security Plan

3.3.3 Required Deliverables

Technical Proposal High Level Design System Design Document

3.3.4 Other Artifacts

None

3.3.5 Process Flow

NSF DIS Design Phase Process Flow

D-07 Conduct Peer

Review

D-12 Create

Management Review Package

D-13 Conduct Design

Gate Review

D-03 Conduct Peer

Review

D-02 Develop the

Technical Proposal

D-21 Update the RTM

D-04 Conduct NSF

Review

D-01 Determine

Whether to Build, Buy, or Reuse Components

START D-06

Develop High Level Design

END

D-05 Conduct TaSS

Review

D-08 Conduct NSF

Review

D-09 Conduct TaSS

Review

D-17 Conduct NSF

Review

D-16 Conduct Quality

Assurance Review

D-15 Conduct Peer

Review

D-14 Develop System

Design Document

D-20 Baseline the

SDD

D-11 Begin System Security Plan

D-19 Update System

Security Plan

D-10 Major

Application?

Yes

No

D-18 Major

Application?

Yes

No

3.3.6 Design Phase Process

D-01 Determine whether to Build, Buy, or Reuse Components

Responsible Party

Project Team

Input SRS, Technical Proposal Template

Description Research current NSF capabilities to find reusable components.

Research past solutions to find reusable components.

Perform market research to determine industry best practices and off-the-shelf solutions.

Schedule demos with selected vendors (if applicable).

Evaluate technical capabilities of off-the-shelf solutions; including whether off-the-shelf solutions security controls meet technical security requirements as specified by project requirements and/or federal and NIST guidance (e.g.

the National Information Assurance Partnership [NIAP] Common Criteria Evaluation and Validation Program) as outlined in NIST 800-23 Guidelines to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products.

Consult with the IT Security Team to determine the appropriate security baseline requirements.

Survey current technical in-house capabilities to determine if capabilities exist to build the product.

Perform cost-benefit analysis of building, buying, or reusing product components.

Meet with TaSS to determine if a Technical Proposal or High-Level Design needs to be developed

Document the technical solution decision using the Technical Proposal Template.

Tools Technical Proposal Template

Output Draft Technical Solution

D-02 Develop the Technical Proposal

Responsible Party

Project Team

Input Technical solution

Description Project team prepares the Technical Proposal

Tools Technical Proposal Template

Output Draft Technical Proposal

D-03 Conduct Peer Review

Responsible Party

Project Team

Input Technical Proposal

Description Project team performs a peer review of the Technical Proposal that includes cross team technical architecture resources

Tools Peer Review Summary Report Template

Output Peer Review Summary Report Template

Updated Technical Proposal

D-04 NSF Project Lead Review

Responsible Party

NSF Project Lead

Input Technical Proposal

Description The NSF Project Lead reviews the Technical Proposal and provides comments and feedback.

The Project Team updates the Technical Proposal to address the NSF Lead comments

Tools N/A

Output Comments/Feedback on Technical Proposal

Updated Technical Proposal

D-05 TaSS Review

Responsible Party

TaSS

Input Technical Proposal

Description The purpose of the Technical Proposal is to present TaSS with the options considered for the project. This project could be an OLTP (web based) application, a COTS implementation, an infrastructure change or an enterprise service. The TaSS provides a recommendation based on alignment with NSF Enterprise Architecture and standard architecture guidelines.

Tools CIP Template: SDLC Tools -> Design -> Technical Proposal Template

NSF Architecture Profile

Target Reference Architecture (In Development)

Output Comments/Feedback on Technical Proposal

Updated Technical Proposal

D-06 Develop High Level Design Document

Responsible Party

Project Team

Input SRS, RTM, Approved Technical Proposal, High Level Design Template

Description Construct, expand, or reuse a service-oriented High-Level Design by analyzing inputs to develop, document, and maintain the high-level design including interfaces, and ensure the logical architecture is consistent with the TaSS developed System Reference Architecture (SRA).

Design architecture in accordance with applicable standards.

Re-use existing products, services and/or components where possible.

Map product capabilities (environment, security, product, and interface requirements) and functional capabilities into services and/or components.

Per the SRA, define/distinguish services vs. components for each piece of functionality.

Document physical architecture/infrastructure Document the High-Level Design using the High-Level Design Template.

Tools CIP Template: SDLC Tools -> Design -> High Level Design Template

Output Draft High Level Design

D-07 Conduct Peer Review

Responsible Party

Project Team

Input Draft High Level Design

Description Project team performs a peer review of the High Level Design that includes cross team technical architecture resources.

Project team incorporates any feedback/comments

Tools Peer Review Summary Report Template

Output Peer Review Summary Report Template

Updated High Level Design

D-08 Conduct NSF Review

Responsible Party

NSF Project Lead

Input High Level Design

Description NSF Project Lead performs review of the High Level Design and provides comments and feedback.

Project Team incorporates NSF Project Lead comments/feedback

Tools N/A

Output Comments/Feedback on High Level Design

Updated High Level Design

D-09 Conduct TaSS Review

Responsible Party

TaSS

Input High Level Design

Description The High Level Design has to be based on the recommended option selected after the TaSS review of the Technical Proposal. TaSS reviews the High Level Design and provides recommendations for improvement and alignment with the Target Reference Architecture.

TaSS will optionally create Change Requests to track any Action Items based on the review. The Project Team uses the Change Requests to incorporate TaSS comments/feedback.

Tools NSF Architecture Profile

Target Reference Architecture (In Development)

Output Comments/Feedback on High Level Design

Updated High Level Design

D-10 Major Application?

Responsible Party

DIS Security Team

Input Major Application Criteria

Description DIS Security reviews the Information Categorization Form and High Level Design to determine whether the application meets the criteria for a major application.

Output Application categorized as major or minor

D-11 Begin System Security Plan

Responsible Party

DIS Security Team

Input Approved High Level Design

Description If the application is categorized as a major application, then a System Security Plan is required. Based on the information in the High Level Design, the DIS Security Team creates the initial draft of the System Security Plan (SSP). The plan should define all aspects of system security (e.g. authentication process, level of access).

Tools SSP Template

Output Draft SSP

D-12 Create Management Review Package

Responsible Party

Project Team

Input Technical Proposal; High Level Design; Design Review Briefing Template

Description Project Team compiles the management review package for the Design Gate Review

Tools Design Review Briefing Template

Output Management Gate Review Package

D-13 Conduct Design Gate Review

Responsible Party

DIS Senior Leadership / Business Owner

Input Management Gate Review Package

Description Conduct review meeting with DIS Senior Management, Architect, Operations, and Business Owner(s). Capture any key decisions or actions during the review meeting.

Tools Design Review Briefing Template

Output Key Decisions and Actions

D-14 Develop System Design Document

Responsible Party

Project Team

Input Approved High Level Design, SRS, RTM, Draft SSP, System Design Document (SDD) Template

Description Work with stakeholders to complete the design methodology, architecture, data architecture and application designs, including all relevant sub-sections like UI design, technical dependencies, and a data dictionary.

Decompose High-Level design into the lowest level product components/services and ensure the logical architecture is consistent with the TaSS developed SRA.

Design inter-component interfaces, user/system interfaces, database, and software/hardware interfaces.

Draft the SDD using the SDD Template.

Tools SDD Template

Output Draft SDD

D-15 Conduct Peer Review

Responsible Party

Project Team

Input Draft SDD

Description Project team performs a peer review of the High Level Design that includes cross team technical architecture resources.

Project team incorporates any feedback/comments

Tools Peer Review Summary Report Template

Output Peer Review Summary Report Template

Updated SDD

D-16 Conduct Quality Assurance Review

Responsible Party

Quality Assurance Team

Input Updated SDD

Description QA Team performs quality assurance review of the Updated SDD and provides comments/findings

Project team incorporates QA comments and addresses findings

Tools Quality Assurance Review Criteria

Output Quality Assurance Findings

Updated SDD

D-17 Conduct NSF Review

Responsible Party

NSF Project Lead

Input Updated SDD

Description NSF Project Lead performs review of the Updated SDD and provides comments/feedback

Project Team incorporates comments/feedback

Tools N/A

Output Comments/Feedback on Updated SDD

Updated SDD

D-18 Major Application?

Responsible Party

DIS Security Team

Input Major Application Criteria

Description DIS Security reviews the Information Categorization Form and High Level Design to determine whether the application meets the criteria for a major application.

D-19 Update System Security Plan

Responsible Party

DIS Security Team

Input Draft SSP

Description If a major application, DIS Security updates the SSP based on the information provided in the system design document

Tools N/A

Output Updated SDD

D-20 Baseline the System Design Document

Responsible Party

Project Team

Input Approved SDD

Description Project Team baselines the System Design Document in accordance with the Software Configuration Management Plan.

Tools Software Configuration Management Plan

Output Baseline SDD

D-21 Update the Requirements Traceability Matrix

Responsible Party

Project Team

Input Approved SDD, SRS, RTM

Description Trace requirements to the lowest level product component and update the RTM

Tools RTM

Output Updated RTM

3.4 Development Phase

3.4.1 Purpose

The Development phase focuses on transforming the design into a working system that satisfies all the requirements. Any special procedures for data conversion and/or data warehousing will also be developed and tested during this phase.

3.4.2 Certification & Accreditation (C&A) Activities (If Major Application)

System Security Plan

3.4.3 Required Deliverables

Baselined Code Product Integration Document(s) Deployment Description Document

3.4.4 Other Artifacts

Unit Test Checklist Code Review Checklist

3.4.5 Process Flow

NSF DIS Development Phase Process Flow

DEV-05

Conduct Unit

Testing

DEV-02

Develop Product

Components

DEV-09

Update the RTM

DEV-01

Establish the Development Environment

START END

DEV-06

Conduct Code Review

DEV-04

Update System

Security Plan

DEV-08

Update Design

Documents

DEV-03

Major

Application?

Yes

No

DEV-07

Create

Deployment Description Document

3.4.6 Development Phase Process

DEV-01 Establish the Development Environment

Responsible Party

Project Team

Input ConOps document, High Level Design document, RTM, SRS, Change Management Procedure

Description Develop product integration documentation (e.g. software build directive, installation instructions) and coordinate with IMB to determine access to web and application servers, and/or appropriate accounts.

Database access – setup, accounts, JDBC resource creation File server access Refer to the Change Management Procedure for establishing a CM

Environment and determining CM standards and requirements (e.g.

ClearQuest and ClearCase)

Tools ConOps document, High Level Design document, RTM, SRS, Change Management Procedure

Output Product Integration Document(s)

DEV-02 Develop Product Components

Responsible Party

Project Team

Input High Level Design document, RTM, SRS, SDD

Description Develop product components implementing baselined requirements and design.

Ensure applicable standards are applied (e.g., coding and configuration standards, style guides, and policies).

Tools ConOps document, High Level Design document, RTM, SRS, SDD

Output Integrated Product Components

Product Integration Documents

DEV-03 Major Application?

Responsible Party

DIS Security Team

Input Major Application Criteria

Description DIS Security reviews the Information Categorization Form and High Level Design to determine whether the application meets the criteria for a major application.

Tools N/A

Output Application categorized as major or minor

DEV-04 Update System Security Plan

Responsible Party

DIS Security Team

Input Product Integration Documents

Description If a major application, DIS Security updates the System Security Plan with any changes resulting from development

Tools System Security Plan Template

Output Updated System Security Plan

DEV-05 Conduct Unit Testing

Responsible Party

Project Team

Input Integrated Product Components

Description Create and document lowest-level component test cases and data. Perform lowest-level component testing (e.g., unit testing).

Tools Unit Test Checklist

Output Unit Test Artifacts

DEV-06 Conduct Code Review

Responsible Party

Project Team, Project Manager,…