EPA SLCM Procedure Guidance

8/7/2019 EPA SLCM Procedure Guidance

1/59

U.S. Environmental Protection Agency

ATTACHMENTS TO THESYSTEM LIFE CYCLE MANAGEMENT

(SLCM) PROCEDURE(GUIDANCE)

Document Number XXX.X

January 10, 2007


2/59

System Life Cycle Management Guidance DRAFT Not for Distribution Page i Updated: 1/10/07

Table of Contents

SLCM Phase Descriptions:Attachment 1: Definition Phase ......................................................................................... 2

A. Concept Exploration Subphase................... .................. .................. .................. .................. . 2B. System Planning Subphase ................ .................. .................. .................. ................. ........... 7C. Requirements Subphase and Control Gate # 1 EA Compliance Certification Review andSystem Selection ................. ................. .................. ................. .................. ................. ............. 14

Attachment 2: Acquisition/Development Phase .............................................................. 18A. Acquisition Subphase ................. .................. .................. .................. .................. ............... 18B. Design Subphase and Control Gate # 2 - EA Compliance Certification Review.............. 22 C. Development Subphase ............... .................. .................. .................. .................. .............. 30D. Test Subphase and Control Gate # 3 - Authorization to Operate .................. ................... . 34

Attachment 3: Implementation Phase .............................................................................. 38Attachment 4: Operations & Maintenance Phase and Control Gate # 4 Modify orTerminate .......................................................................................................................... 42Attachment 5: Termination Phase.................................................................................... 50

Guidance on Control Gate Reviews:Gate 1 - EA Compliance Certification and System Selection Review ............................. 54Gate 2 - EA Compliance Certification Review................................................................. 54Gate 3 Authorization to Operate Review....................................................................... 55Gate 4 Modify or Terminate Review............................................................................. 55

SLCM Tools:Supporting Document Checklist for System Life Cycle Management............................. 57


3/59


4/59

System Life Cycle Management Guidance DRAFT Not for Distribution Page 3 Updated: 1/10/07

Every project must have a responsible organization and sufficientresources to execute the project. The Concept Proposal should identifywhy a business process is necessary and what business benefits can beexpected by implementing this improvement. It is important to state theneeds or opportunities in business terms. Avoid identifying a specificproduct or vendor as the solution. The Concept Proposal should beapproximately 2-5 pages in length. The background information providedshould be at a level of detail sufficient to familiarize senior managers withthe history, issues and customer service opportunities that can be realizedthrough improvements to business processes with the potential support of IT. This background information must not offer or predetermine anyspecific automated solution, tool, or product.

The System Sponsor is the principal authority on matters regarding theexpression of business needs, the interpretation of functional requirementslanguage, and the mediation of issues regarding the priority, scope anddomain of business requirement. The System Sponsor must understandwhat constitutes a requirement and must take ownership of therequirements and input and output.

This activity involves the appointment of a System Manager who carriesboth the responsibility and accountability for project execution. For smallefforts, this may only involve assigning a project to a manager within anexisting organization that already has an inherent support structure. Fornew, major projects, a completely new organizational element may beformed - requiring the hiring and reassignment of technical and businessspecialists.

To provide a management structure for the project, the System Managershould adapt, adopt, or create written processes and procedures forrecurring project activities. These include requirements management,project tracking, contractor management, verification and validation,quality assurance, change management, and risk management.

The results of the efforts of this phase are documented in the ConceptProposal and the Mission Need Statement. The approval of the ConceptProposal identifies the end of the Concept Exploration subphase.Approval should be annotated on the Concept Proposal by the SystemSponsor and/or the Chief Information Officer (CIO).

Once approval to proceed has been given within EPA, a core project teamwith participation of the System Manager must be established in order tomove on to the System Planning Subphase .


5/59


6/59


Work Product Status

Approvals (Decision Papers) (SMP)Document decisions presented to management. Summarize those aspects of the

analysis and decisions of a given phase or subphase that are important toprogram management and requests approval to continue the project. The EPAlife cycle model provides for decision papers to be prepared at the beginning of the Definition, Development or Acquisition, Implementation, and RetirementPhases and at the end of the Requirements Subphase. The level of detail fordecision papers should be appropriate to the category of the system.

B

Business CaseThe compelling business rationale and justification for developing ormodernizing a system. It describes current business processes, possibly usingactivity and data models. Current costs and performance are also associatedwith the models. Gaps between current and desired outcomes are identified andanalyzed. Alternatives for improving the business are developed and evaluatedbased on readily available information. This is a document that is a componentof SMP.

D

Change DirectiveDocuments the formal Change Control Document to implement an approvedchange.

Change Tracking LogLog that records the status of all changes proposed to the SMP, including adescription of the proposed change, the status history, and final disposition.

Concept of OperationsDescribes Business process and how system is used in support of the process. B

Concept Proposal Describes the need or opportunity to improve business functions. It identifieswhere strategic goals are not being met or mission performance needs to beimproved.

B

Cost-Benefit AnalysisDocuments costs and proposed benefits of alternatives. D

Information CategorizationTypes of information that will be collected and processed should be identifiedand categorized in accordance with FIPS 199 and NIST SP 800-60, to the extentknown, including Privacy Act type information. Further refinement will beneeded throughout the life cycle.

D

IT Project RequestServes as the formal budget request for the project. Most of the informationrequired for the IT Project Request is obtained from the Business Case and theProject Risk Management Plan.

B

Mission Need StatementDocuments the results of a mission analysis, serves as the decision document

for the mission need decision, and after final approval, serves as the basis forinvestment analysis. It provides a clear, unambiguous, and quantitativedescription of the mission area, current capability, capability shortfall ortechnology opportunity, required operational capability, impact of disapproval,benefits, time frame, critically, and resource estimate. This product is acomponent of the SMP.

B

Privacy Impact AssessmentBased on the initial FIP 199 categorization and the identification of the need orpotential to collect Privacy Act data/information, the assessment required by the

B


7/59


Work Product Status

Privacy Act and/or E-Government Act of 2002 to conduct assessments oninvestments before developing or procuring information technology that

collects, maintains, or disseminates information that is in an identifiable form.Project PlanDocuments the schedule and time frame for system development activities tooccur based on the estimates developed in the previous phases, as well as task dependencies, organization priorities, and resource availability.

D

Project Risk Management Plan (SMP)Identifies and categorizes risks to the successful completion of the project.Lists each identified risk, describing its probability of occurrence, potentialconsequences, and degree to which it can be controlled. Strategies foreliminating or mitigating each risk are documented.

D

Security ConceptDocuments a preliminary analysis of security considerations for the newsystem. It provides the first look at the information that might be included in

the Security Plan. Areas considered include risks from theft, disclosure,unauthorized access, eavesdropping, programmed attacks, incorrect routing,misplacement, erasure, and accidental damage. Includes an initial analysis of FIPS 199/NIST 800-60 categories and impact levels of the data and resultinginformation system. Based on this information, an initial baseline of securitycontrols will be identified from FIPS 201 and NIST SP 800-53.

D

Security Risk AssessmentBegins assembling and analyzing threat, and vulnerability information draftingan initial qualitative determination of risk to a collection of sensitive data andthe people, information systems, and installations involved in transmitting,accessing and processing that data. Its purpose is to inform the selection ormodification of required controls from FIPS 201 and NIST SP 800-53 based onthe information's FIPS 199 impact levels to provide cost-effective and adequatesecurity.

D

Solution ArchitectureDescribes how an individual information management system, or informationacquisition, will comply with the requirements of the Target Architecture,which is the set of products that portrays the future state of the Agency. ASolution Architecture is a comprehensive architectural response to a businessproblem. Solutions address all layers of Enterprise Architecture - strategy,business, data, applications and technology/security.

B

System Concept DocumentDescribes the results of all significant functional analyses conducted during thissubphase, including definition of high level requirements, assessment of pertinent existing information processing capabilities, complete formulation of alternative system functional concepts, assessment of the alternatives, andrationale for the selection of the recommended concept. The data portiondescribes high-level data requirements for the recommended system concept,provides definitions of these requirements, charts the logical structure of thedata requirements, and describes sources, uses, and distribution of data. Itdefines the system concept, and includes, if applicable, a feasibility study,alternatives analysis, and acquisition strategy.

B


8/59


Attachment 1: Definition Phase

B. System Planning Subphase

Process Description: The System Planning Subphase begins when the Concept Proposalhas been formally approved and funded. This phase requires studyand analysis that may lead to system development activities.Following review and approval of the Concept Proposal, some formof EPA approval (tasking directive) should be issued to begin theformal studies and analyses of the need. The issuing of the taskingdirective initiates the System Planning Subphase and begins the lifecycle of an identifiable project. This subphase is also the start of theSystem Management Plan.

ProcedureDescription:

The following activities are performed as part of the System PlanningSubphase . The results of these activities are captured in the SystemManagement Plan, the Business Case and the Project Risk Management Plan and their underlying institutional processes andprocedures.

The System Management Plan (SMP) is the primary managerialdocumentation in the life cycle of an information system. Thevarious components of this document can be tailored to the projects

classification and may include: Change Tracking Log Mission Need Statement Business Case System Operations and Maintenance Concept Responsibilities Cost-Benefit Analysis Summary Schedule Project Risk Management Plan Security Plan and Security Categorization Quality Assurance Plan Configuration Management Plan Review Sections

o Data Standardso Enterprise Architecture (EA) Alignmento Capital Planning and Investment Control (CPIC)

Approvals (Decision Papers)


9/59


Waivers Work Breakdown Structure Application Deployment Checklist

The project team, supplemented by enterprise architecture experts if needed, determines the acquisition strategy by analyzing all feasibletechnical, business process, and commercial alternatives to meetingthe business need. These alternatives are analyzed from a life cyclecost perspective. The results of these studies show a range of feasiblealternatives based on life cycle cost, technical capability, operationalfeasibility and scheduled availability. Typically, these studies narrowthe system technical approaches to only a few potential, desirablesolutions that then proceed into the subsequent life cycle phases.Caution is needed to ensure new and/or creative design concepts arenot eliminated from consideration.

The project team plans the subsequent phases to allow developmentof the project schedule and budget requirements, and to define theexpected performance benefits. The Business Case summarizes thehigh level requirements for the project and justifies the need.

The project team identifies all alternatives that may address the needand any programmatic or technical risks. The risks associated withfurther development are also studied. The results of theseassessments are summarized in the Business Case and documented inthe Project Risk Management Plan.

The results of the phase efforts are presented to project stakeholdersand decision makers together with a recommendation to do one of thefollowing:

Proceed into the next life cycle phase Continue additional conceptual phase activities Terminate the project

The emphasis of the review is on:

The successful accomplishment of the phase objectives The plans for the next life cycle phase The risks associated with moving into the next life cycle

phase

The review also addresses the availability of resources to execute thesubsequent life cycle phases. The results of the review aredocumented reflecting the decision on the recommended action.


10/59


Responsibilities: System Manager: The System Manager is responsible andaccountable for the successful execution of the System Planning

Subphase . The System Manager is responsible for leading the teamthat accomplishes the tasks shown above, and is ultimatelyresponsible for the quality of the finished product.

Project Team: The project team members (regardless of theorganization of permanent assignment) are responsible foraccomplishing assigned tasks as directed by the System Manager.

Procurement Officer: The Procurement Officer is responsible andaccountable for preparing solicitation documents under the guidanceof the System Manager.

System Sponsor: The System Sponsor is responsible for authorizingand ensuring that the funding and resources are in place to supportthe system.

Oversight Stakeholders: The oversight stakeholders provideoversight, advice and counsel to the System Manager on the conductand requirements of the planning effort. Additionally, oversightstakeholders provide information, judgments, and recommendationsto the EPA decision makers during project reviews and in support of project decision milestones.

System Owner: The System Owner is designated at an appropriatelevel within the EPA as the project decision authority (may or may

not be the same individual designated as the sponsor in the previousphase). This individual is charged with assessing the:

Completeness of the planning phase activities Robustness of the plans for the next life cycle phase Availability of resources to execute the next phase Acceptability of the acquisition risk of entering the next phase

For applicable projects, this assessment also includes the readiness toaward any major contracting efforts needed to execute the next phase.

During the end of phase review process, the decision maker does oneof the following:

Directs the project to move forward into the next life cyclephase (including awarding contracts)

Directs the project to remain in the planning phase pendingcompletion of delayed activities or additional risk reduction


11/59


efforts

Terminates the project

Project LevelReviews:

A review is performed at the end of the System Planning Subphase .The review ensures that the goals and objectives of the system areidentified and that the feasibility of the system is established.Products of the System Planning Subphase are reviewed including thebudget, risk, and user requirements. This review is organized,planned, and led by the System Manager and/or representative.Approval of the Business Case by the SIO grants approval to proceedto the Requirements Phase of the SLC. It is important in this effortnot to eliminate new and creative approaches. Emphasis should be onthe total cost of ownership and not just a single system concept.Support and training issues may become very important from thisperspective.

After the Business Case is approved and a recommendation isaccepted by the SIO and System Sponsor, the system project planningcan begin.

As identified in the Definition Phase , each project has an individualdesignated to lead the effort. The individual selected has appropriateskills, experience, credibility, and availability to lead the project.Clearly defined authority and responsibility must be provided to theSystem Manager.

The System Manager works with the SIO and System Sponsor toverify the scope of the proposed program, participation of the keyorganizations, and potential individuals who can participate in theformal reviews of the project. This decision addresses bothprogrammatic and information management-oriented participation aswell as technical interests in the project that are known at this time.

In view of the nature and scope of the proposed program, the keyindividuals and oversight stakeholders who are the approvalauthorities for the project should be identified, including the sign-off for quality assurance.

The System Manager and System Sponsor determine if anyparticularly unusual programmatic, technical, or informationmanagement skills or experience are needed. Organizations notparticipating directly in the project may be notified, if appropriate,including external organizations. Whenever the concept is sharedamong multiple organizations, data administration plays a strong role.

Management approval to commit resources to the proposed program


12/59


marks the beginning of the subsequent system development life cyclephases.

The feasibility analysis and cost benefit analysis confirm that thedefined information management concept is significant enough towarrant an IT project with life cycle management activities.

The feasibility study analysis confirm that the informationmanagement need or opportunity is beyond the capabilities of existingsystems and that developing a new system is a promising approach.

The Cost-Benefits Analysis confirms that the projected benefits of theproposed approach justify the projected resources required.

Work Products:

D = Draft: Preliminary version of work product/working copyB = Baseline: Completed version of work product (with signoff if applicable)U = Update: Completed version showing changes made to the baseline version

= Always Required

Work Product Status

Acquisition Strategy BApplication Deployment Checklist - (SMP) The expected or projected platform(s) and locations on which an applicationwill reside, requires knowledge of the requirements for deployment on thatplatform. Application deployment checklists should be obtained andrequirements identified and factored into the system planning as soon aspossible.

D

Approvals (Decision Papers) - (SMP) B

Business Case - (SMP) B

Change Directive

Change Tracking Log - (SMP) Configuration Management Plan - (SMP)Describes the overall plan for identifying and controlling the parts of the systemto ensure its proper functioning according to its requirements.

B

Contract Security RequirementsRequirements for contractor background checks, and controls to protect anydata used in development, non-disclosures, and separation of duties or need-to-know controls need to be spelled out for inclusion in any contracts in the nextphase.

B

Cost Benefit Analysis - (SMP) BData Standards - (SMP)Technical specifications for the defining, naming, and using of data within the

D


13/59


14/59


15/59


Attachment 1: Definition Phase

C. Requirements Subphase andControl Gate # 1 EA Compliance Certification Review andSystem Selection

ProcessDescription:

The Requirements Subphase begins when the previous phasedocumentation has been approved or by management direction.Documentation related to user requirements from the System PlanningSubphase is used as the basis for further user needs analysis and thedevelopment of detailed user requirements. The analysis may revealnew insights into the overall information systems requirements. In

such instances, all work products are revised to reflect this analysis.During the Requirements Subphase , the system is defined in moredetail with regard to system inputs, processes, outputs, and interfaces(both internal and external). This definition process occurs at thefunctional level. The system is described in terms of the functions to beperformed, not in terms of computer programs, files, and data streams.The emphasis in this phase is on determining what functions must beperformed rather than how to perform those functions, and ensuringdata quality should be considered. This is best done through firstidentifying outputs, inputs, and processes. During the RequirementsSubphase

, the project team: Further defines and refines functional and data requirements Completes business process engineering of the functions to be

supported

Develops detailed data and process models Defines functional and system requirements that are not easily

expressed in data and process models. Functional and systemrequirements also include the requirements of the businessprocess, the user requirements, and operational requirements

Refines the high level architecture and logical design to supportthe system and functional requirements

Continues to identify and mitigate risk that the technology can bephased-in and coordinated with the business.


16/59



The tasks described below are performed during the RequirementsSubphase .

The business needs are consolidated and affirmed. The functionalrequirements and the data requirements are then consolidated. Thefunctional requirements are connected to the data requirements.

The Functional Requirements Document (FRD) is a record of the aboverequirements. This can be established as a matrix and tracked forsatisfaction of every module of the system as development progresses.

The Functional and Data Requirements Review is conducted in the Requirements Subphase by the SIO and System Sponsor to ensure thatthe business requirements have been accurately linked to functional and

data requirements.

The Concept Exploration Subphase documentation may need to berevised or updated. The System Planning Subphase documentation mayalso need to be updated in this phase.

Responsibilities: System Manager: The System Manager is responsible andaccountable for the successful execution of the Requirements subphase.The System Manager is responsible for leading the team thataccomplishes the tasks shown above.


Procurement Officer: The Procurement Officer is responsible andaccountable for preparing solicitation documents under the guidance of the program manager.

Quality Assurance Staff: The Quality Assurance Staff is responsiblefor continually reviewing the state of the product so the rest of the teamcan focus on their tasks. Quality Assurances goal is to support theproduct development processes.

Oversight Stakeholders: The oversight stakeholders provide oversight,advice and counsel to the System Manager on the conduct andrequirements of the planning effort. Additionally, oversightstakeholders provide information, judgments, and recommendations tothe EPA decision makers during project reviews and in support of project decision milestones.


17/59


Control Gate 1System Selection:

At the end of the Definition Phase is the EA Compliance CertificationReview and System Selection Control Gate. This ensures the business

justification is accurate and complete and approves the IT InvestmentBusiness Case for inclusion in the EPA IT Portfolio. The systemselection decision process is described in EPA Order 2100.3, CapitalPlanning and Investment Control (CPIC) Program Policy for

Management of Information Technology (IT) Investments..

Upon completion of all Requirements Subphase tasks and receipt of resources for the next phase, the System Manager, together with theproject team, prepares and presents a project status review for the SIO,IIS, System Sponsor, and other stakeholders. The review addresses:

Requirements Subphase required work products, whichmust be complete, approved, and verified

Planning status for all subsequent life cycle phases (withsignificant detail on the next phase, to include the statusof pending contract actions)

Resource availability status Acquisition risk assessments of subsequent life cycle

phases given the planned acquisition strategy

Work Products:


= Always Required

Work Product Status

Acquisition Strategy U

Approvals (Decision Papers) - (SMP) B

Change Directive

Change Tracking Log

Concept of Operations U

Contract Security Requirements B

Cost Benefit Analysis U


18/59


Work Product Status

Functional Requirements DocumentServes as the foundation for system design and development; captures user

requirements to be implemented in a new or enhanced system; the systems subjectmatter experts document these requirements into the requirements trace abilitymatrix, which shows mapping of each detailed functional requirement to its source.

B

Hardware Requirements Specification B

Information Categorization BInterface Requirements SpecificationSpecifies the requirements imposed on one or more systems, subsystems, HardwareConfiguration Items, Computer Software Configuration Items, manual operations,or other system components to achieve one or more interfaces among these entities.

B

Project Plan U

Records Management Disposition Schedule B

Security ConceptDocuments a preliminary analysis of security considerations for the new system. Itprovides the first look at the information that might be included in the SecurityPlan. Areas considered include risks from theft, disclosure, unauthorized access,eavesdropping, programmed attacks, incorrect routing, misplacement, erasure, andaccidental damage. Includes an initial analysis of FIPS 199/NIST 800-60 categoriesand impact levels of the data and resulting information system. Based on thisinformation, an initial baseline of security controls will be identified from FIPS 201and NIST SP 800-53.

B

Security Plan - (SMP)Begins the development of the security plan which describes the plan to meetsecurity and privacy protection requirements. It addresses what is known to dateabout the impact levels, conceptual information system architecture, risks, required

controls, contingency or continuity of support needs, laws and penalties that mayapply to breach of confidentiality, etc." Establishes the security requirements andformalizes security process for system. Required for every system.

B

Preliminary Security Risk Assessment B

Software Requirements Specification B

Solution Architecture USystem Engineering Management PlanDocuments the plan, articulation, and approval of the strategy to execute thetechnical management aspects of the project (SEMP).

D

System Test PlanDescribes the specific tests and test cases to be used to evaluate the system atappropriate points in the systems SLC consistent with the TEMP. Security testingcomes primarily from NIST SP 800-53a which will correspond to each securitycontrol. Additionally, usability and other programmatic acceptance criteria testingshould be planned for that will contribute to system acceptance and authorizations.

D

Test and Evaluation Master Plan (TEMP)Defines the overall strategy for ensuring that the developed and implementedsystem conforms to all requirements. The TEMP describes the types of testing thatwill be acceptable for use at various points in the systems SLC and whatconstitutes successful testing.

B


19/59


20/59


Subphase are followed. The information in the plan is as follows:

Adequate information for making management decisionsconcerning procurement of government human resourcesand services, contractor services procurement, including

ensuring the availability of funding Adequate information for performing a technical analysis

and evaluation of vendor proposals

Adequate information for vendors to prepare bids Adequate information for the source selection official to

base a selection

The following are considered when submitting a request for hardware,software, and/or related services:

Resources are consistent with applicable laws, regulations,

policy/procedural guidance from central managementagencies, Congress, and senior Agency management

Acquisitions are consistent with Agency objectives andinitiatives as defined in the EPA EA

Resources are obtained only in direct support of the EPAmissions and programs of the acquiring office/organization

Acquisitions are not redundant or duplicative effortsresulting in wasted money, time, and resources

Resources represent the most efficient and cost-effective

means of providing automated supportCaution is needed to ensure new and/or creative design concepts areconsidered. The Acquisition Subphase typically has its own mini-lifecycle of pre-solicitation, solicitation and award, and post award. Thelife cycle model varies according to the system development effort; thismeans that the activities in each differ significantly. The modelAcquisition Plan includes a milestone schedule, with estimatedcompletion dates.

The Acquisition Subphase becomes critical after the FunctionalRequirements Document has been approved. Several acquisitions may

be needed to procure an entire system and are a continuous part of thelife cycle. The Acquisition Plan is continuously updated with theactive involvement of the System Manager.

Responsibilities: System Manager: The System Manager works directly withacquisitions personnel to ensure the timely award of the needed


21/59


resources. The Acquisition Subphase is developed as required by theFederal Acquisition Regulation (FAR) 7.103. The System Manager isresponsible and accountable for the successful execution of the

Acquisition Subphase . The System Manager is responsible for leadingthe team that accomplishes the tasks shown above.

Project Team: The project team members (regardless of theorganization of permanent assignment) are responsible foraccomplishing assigned tasks as directed by the System Manager. Mayinclude Program Analysts or Programmers who interpret userrequirements, designs and writes the code for specialized programs.

Procurement Officer: The Procurement Officer is responsible andaccountable for preparing solicitation documents under the guidance of the System Manager.


System Owner: At an appropriate level within the EPA, an individualis designated as the project decision and quality authority (may or maynot be the same individual designated as the sponsor in the previousphase). This individual is charged with assessing:

The completeness of the Acquisition Subphase activities

The robustness of the plans for the next life cycle phase The availability of resources to execute the next phase The acceptability of the risk of entering the next phase The quality of the products produced in each phase

For applicable projects, this assessment also includes the readiness toaward any major contracting efforts needed to execute the next phase.At the end of phase review process, the decision maker does one of thefollowing:

Directs the project to move forward into the next life cyclephase (including awarding contracts)

Directs the project to remain in the acquisition subphasepending completion of delayed activities or additional risk reduction efforts

Terminates the project


22/59



A review is performed at the end of the Acquisition Subphase . Thereview ensures that the requirements of the system are identified andthat the feasibility of the system is established. Products of the

Acquisition Subphase are reviewed including the Acquisition Plan andthe requirements specifications. This review is organized, planned, andled by the System Manager and/or representative. Approval of theContract for Services by the Procurement Officer grants approval toproceed to the Design Subphase .

Work Products:


= Always Required

Work Product Status

Acquisition PackageDocuments allocation of the requirements among development segments,research and applies lessons learned from previous projects; identifies potentialproduct and service providers, and secures funding.

B

Acquisition Strategy UApprovals (Decision Papers) (SMP) BBidders List

List of eligible and interested bidders, bidding on a contract. B

Change Directive

Change Tracking Log ContractDocument that establishes an offer and consideration for goods and/or services. B

Full Security Risk Assessment B

Project Plan U

Request for Proposal B

Solution Architecture U


23/59


Attachment 2: Acquisition/Development PhaseB. Design Subphase andControl Gate # 2 - EA Compliance Certification Review

ProcessDescription:

The objective of the Design Subphase is to transform the detailed,defined requirements into complete, detailed specifications for thesystem that will guide the work of the Development Subphase . Thedecisions made in this phase address, in detail, how the system willmeet the defined functional, physical, interface, and data requirements.

Design Subphase activities may be conducted in an iterative fashion,producing first a general system design that emphasizes the functionalfeatures of the system, then a more detailed system design that expandsthe general design by providing all the technical detail.

For Commercial Off-the-Shelf (COTS) products, some tasks andactivities may have been performed by the vendor and vendordocumentation may be appropriate to meet some documentationrequirements. This is acceptable as long as each task and activity isperformed and each document is available.

Procedure

Description:

The following tasks are performed during the Design Subphase.

The System Design Document is developed by the System Managerand project team, identifying the steps used in the design of theapplication/system. The prerequisites for this phase are the BusinessCase, Project Plan, and Functional Requirements Document (FRD).The System Manager and project team identify/specify the targetenvironment, the development environment and the designenvironment. The business organization, roles and procedures fordesigning this system/application are articulated. The System DesignDocument is a work product in the Design Subphase . Documents fromthe previous phases are revised during the Design Subphase . The

updates are signed off by the System Manager with significant changesapproved by the System Sponsor and CIO.

In the system design, first the general system characteristics aredefined. The data storage and access for the database layer aredesigned. The user interface at the desktop layer is designed. Thebusiness rules layer or the application logic is designed. The interfaces


24/59


from application to application and application to database also aredesigned and documented.

A security risk assessment is conducted by addressing the followingcomponents: assets, threats, vulnerabilities, probability of risk occurence, consequences and safeguards. The risk assessmentevaluates compliance with baseline security requirements, identifiesthreats and vulnerabilities, and assesses alternatives for mitigating oraccepting residual risks. A Contingency Plan/COOP is developedcontaining emergency response procedures; backup arrangements,procedures and responsibilities; and post-disaster recovery proceduresand responsibilities. It is included in this phase because many of thesefactors will affect the design of the system. The developer obtains therequirements from the Security Risk Assessment and the FRD andallocates them to the specific modules within the design forenforcement purposes. For example, if a requirement exists to audit aspecific set of user actions, the developer may have to add a workflowmodule into the design to accomplish the auditing. Security operatingprocedures are guidance documents that provide users andadministrators with detailed requirements on how to operate andmaintain the system securely. They should address all applicablecomputer and telecommunications security requirements, including:system access controls; marking, handling, and disposing of magneticmedia and hard copies; computer room access; account creation,access, protection, and capabilities; operational procedures; audit trailrequirements; configuration management; processing area security;employee check-out; and emergency procedures. Security operatingprocedures may be created as separate documents or added as sectionsor appendices to the user and operations manuals. This activity shouldbe conducted during the Design Subphase .

The system user community is included in Design Subphase actions asneeded. New or further requirements might be discovered that arenecessary to accommodate individuals with disabilities. If so, theserequirements are added to the FRD.

Development of the following system documents is started in thisphase:

Maintenance Manual: to ensure continued operation of the systemonce it is completed. This manual is completed as a work productin the Development Subphase.

Operations Manual for mainframe systems/applications and theSystem Administrators Manual for client/server


25/59


systems/applications. These manuals are completed as work products in the Development Subphase.

Training Plan and the User Manual are begun during the Design

Subphase . This will be completed as a work product in the Development Subphase .

Conversion Plan, if current information needs to beconverted/migrated/transitioned to the new system. The ConversionPlan is needed especially if processes are re- engineered.

Implementation Plan and Contingency Plan/COOP are designed inthis phase and are work products in the Development Subphase .

Training Plan outlining the objectives, needs, strategy, and

curriculum to be addressed when training users on the new orenhanced information system. The plan presents the activitiesneeded to support the development of training materials,coordination of training schedules, reservation of personnel andfacilities, planning for training needs, and other training-relatedtasks. Training activities are developed to teach user personnel theuse of the system as specified in the training criteria. The TrainingPlan includes a description of the target audience and topics onwhich training must be conducted on the list of training needs. Itincludes how the topics will be addressed and the format of thetraining program, the list of topics to be covered, materials, time,

space requirements, and proposed schedules.The decisions of this phase re-examine in greater detail many of theparameters addressed in previous phases. The design prepared in thisphase is the basis for the activities of the Development Subphase . Theoverall objective is to establish a complete design for the system. Anumber of project approach, project execution, and project continuationdecisions are made in this phase.

Project approach decisions include:

Identification of existing or COTS components that can beused, or economically modified, to satisfy validatedfunctional requirements

Use of appropriate prototyping to refine requirements andenhance user and developer understanding andinterpretation of requirements


26/59


Selection of specific methodologies and tools to be usedin the later life cycle phases, especially the Development and Implementation Phases

Determination of how user support will be provided, howthe remaining life cycle phases will be integrated, andnewly identified risks and issues handled

Project execution decisions include:

Modifications that must be made to the initial informationsystem

Modifications that will be made to current procedures

Modifications that will be made to currentsystems/databases or to other systems/databases underdevelopment

How conversion of existing data will occur

Project continuation decisions include:

The continued need for the information system to exist

The continued development activities based on the needs

addressed by the design

Availability of sufficient funding and other requiredresources for the remainder of the systems life cycle

There is an ongoing interim review of the system design as it evolvesthrough the Design Subphase . Detailed objective system functions,performance requirements, security requirements, and system platformcharacteristics are reviewed. The System Manager conducts the finaldesign review with approval or disapproval by the SIO and the SystemSponsor. This review is conducted as the end of the Design Subphase

and confirms that modifications prompted by earlier reviews areincorporated.

Responsibilities: System Manager: The System Manager is responsible andaccountable for the successful execution of the Design Subphase . TheSystem Manager is responsible for leading the team that accomplishes


27/59


the tasks shown above.


Procurement Officer: The Procurement Officer is responsible andaccountable for preparing solicitation documents under the guidance of the program manager.


Chief Architect: The Chief Architect is responsible for certifying EAcompliance of the Solution Architecture to complete Control Gate #2.System Sponsor : The System Sponsor participates in the final designreview and gives approval or disapproval with the SIO.

Senior Information Official (SIO) : The SIO participates in the finaldesign review and gives approval or disapproval with the SystemSponsor.

Gate 2 EACOMPLIANCECERTIFICATIONREVIEW:

The purpose of the EA Compliance Certification Review is to Ensurethe systems design conforms to the planned Solution Architecture andcontinues to address the business need while remaining in alignmentwith the Agency EA.

The EA Compliance Certification Review is conducted by the Chief Architect who is responsible for certifying that Solution Architecturesare compliant with the Enterprise Architecture. The SIO or designeeconducts the EA Compliance Certification Review and certifiesarchitecture compliance for non-major and small or other systems. TheSolution Architecture is certified as architecturally compliant prior toproject development unless the appropriate waiver is obtained.

During the Control Gate #2 Review, all Acquisition and DesignSubphase required work products must be complete, approved, andverified to satisfy the Control Gate requirement.


28/59


Joint ManagementReviews:

Joint management reviews are required when the project is beingmanaged and/or funded by multiple offices. The determination of whoshould participate in joint management reviews is made during theinitial tailoring process. Joint management reviews for bothrequirements and design are held during the Design Subphase . Prior tothe design reviews, the acquirer shall have reviewed the work productsinitiated, updated, or completed during the Design Subphase .

System/subsystem and software requirements reviews are held at thebeginning of the Design Subphase to resolve open issues regarding thespecified requirements for a software system or subsystem.

A system/subsystem design review is held at the end of the DesignSubphase to resolve open issues regarding any of the following:

The system-wide or subsystem-wide design decisions The architectural design of a software system or

subsystem

A software design review is held at the end of the Design Subphase toresolve open issues regarding one or more of the following:

The software-wide design decisions The architectural design of a software item The detailed design of a software item or portion thereof

(such as a database)

Upon completion of all Design Subphase tasks and receipt of resourcesfor the next phase, the System Manager, together with the project teamshould prepare and present a project status review for the SIO, SystemSponsor, and other stakeholders. The review should address:

Design Subphase required work products, which must becomplete, approved, and verified

Planning status for all subsequent life cycle phases (withsignificant detail on the next phase, to include the status of pending contract actions)

Resource availability status

Acquisition risk assessments of subsequent life cycle phases given theplanned acquisition strategy.


29/59


Work Products:

D = Draft: Preliminary version of work product/working copyB = Baseline: Completed version of work product (with signoff if applicable)

U = Update: Completed version showing changes made to the baseline version= Always Required

Work Product Status

Application Deployment Checklist (SMP) B

Approvals (Decision Papers) (SMP) B

Change Directive

Change Tracking Log Contingency Plan/COOPContains emergency response procedures; backup arrangements, procedures,and responsibilities; and post-disaster recovery procedures and responsibilities.Contingency planning is essential to ensure that systems are able to recover fromprocessing disruptions in the event of localized emergencies or large-scaledisasters. It is an emergency response plan, developed in conjunction withapplication owners and maintained at the primary and backup computerinstallation to ensure that a reasonable continuity of support is provided if eventsoccur that could prevent normal operations.

B

Data Conversion PlanDescribes the strategies involved in converting data from an existing system toanother hardware or software environment. It is appropriate to re-examine theoriginal systems functional requirements for the condition of the system beforeconversion to determine if the original requirements are still valid.

B

Functional Requirements Document UHardware Requirements Specification U

Interface Requirements Specification UMaintenance ManualProvides the definition of the software support environment, the roles andresponsibilities of maintenance personnel, and the regular activities essential tothe support and maintenance of program modules, job streams, and databasestructures.

D

Operations ManualProvides system administrators/computer control personnel/computer operatorswith a detailed operational description of the information system and itsassociated environments, such as machine room operations and procedures.

D

Project Plan URequirements Traceability MatrixGraphically depicts the relationship between requirements, design modules, andtests used to establish that all requirements have been addressed within the systemand that the tests planned for the system will both test all of the components anddemonstrate that the requirements have been met.

B



30/59


Work Product Status

System Design DocumentDescribes the system requirements, operating environment, system andsubsystem architecture, files and database design, input formats, output layouts,human-machine interface, detailed design, processing logic, and external

interfaces. It is used in conjunction with the Functional RequirementsDocument, which is finalized in this phase, to provide a complete systemspecification of all user requirements for the system and reflects the usersperspective of the system design. Will include Database Models Logical/Physical and Physical Network Topologies Logical/Physical

B

System Implementation Plan (SMP)Describes how the information system will be deployed and installed into anoperational system. The plan contains an overview of the system, a brief description of the major tasks involved in the implementation, the overallresources needed to support the implementation effort (such as hardware,software, facilities, materials, and personnel), and any site-specificimplementation requirements.

D

System Test Plan (SMP) B

User Manual Contains all essential information for the user to make full use of theinformation system. This manual includes a description of the system functionsand capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use.

D

User Training Plan Outlines the objectives, needs, strategy, and curriculum to be addressed whentraining users on the new or enhanced information system. The plan presentsthe activities needed to support the development of training materials,coordination of training schedules, reservation of personnel and facilities,planning for training needs, and other training-related tasks.

D


31/59


32/59


each module or software configuration item to be developed.

Responsibilities: System Manager: The System Manager is responsible andaccountable for the successful execution of the Development

Subphase . The System Manager is responsible for leading the teamthat accomplishes the tasks shown above.


Procurement Officer: The Procurement Officer is responsible andaccountable for preparing solicitation documents under the guidanceof the program manager.

Oversight Stakeholders: The oversight stakeholders provideoversight, advice and counsel to the System Manager on the conductand requirements of the planning effort. Additionally, oversightstakeholders provide information, judgments, and recommendationsto the EPA decision makers during project reviews and in support of project decision milestones.


Upon completion of all Development Subphase tasks and receipt of resources for the next phase, the System Manager, together with theproject team prepares and presents a project status review for theSIO, Program Sponsor, and other stakeholders. The review shouldaddress:

Development subphase activities status Planning status for all subsequent life cycle phases (with

significant detail on the next subphase, to include thestatus of pending contract actions)

Resource availability status Acquisition risk assessments of subsequent life cycle

phases given the planned acquisition strategy


33/59


Work Products:

D = Draft: Preliminary version of work product/working copyB = Baseline: Completed version of work product (with signoff if applicable)

U = Update: Completed version showing changes made to the baseline version= Always Required

Work Product Status

Acquisition Package U

Application Deployment Checklist U

Change Directive

Change Tracking Log

Contingency Plan/COOP U

Data Conversion Plan U

Hardware Requirements Specification UIntegration DocumentExplains how the software components, hardware components, or both arecombined and the interaction between them.

B

Maintenance Manual B

Operations Manual B

Project Plan U

Requirements Traceability Matrix U

System Design Document U

Security Risk Assessment USoftware Development DocumentContains documentation pertaining to the development of each unit or module,including the test cases, software, test results, approvals, and any other itemsthat will help explain the functionality of the software.

B

Solution Architecture USystem (Application) SoftwareEntails the disks (or other media) used to store the application software used forthe Test Phase and finalized in this phase before implementation of the system.

D

System Implementation Plan USystem Modules (Code, Test, Implementation, and Operational)Includes development units such as the source code modules, object codemodules, load modules, and job control streams developed to automate therequired business functions. Although these modules are not typicallydocuments but files that reside on the developed system, source code and jobcontrol listings can be printed and included in system documentation for eachunit / module.

D

System Security Plan B

System Test Plan U


34/59


Work Product Status

Test Analysis ReportDocuments the formal documentation of the software testing. B

Test Files / DataProvide the actual test data and files used for system testing. B

User Manual BUser Training Plan B


35/59


Attachment 2: Acquisition/Development Phase

C. Test Subphase andControl Gate # 3 - Authorization to Operate

ProcessDescription:

The objective of the Test Subphase is to prove that the developed systemsatisfies the requirements defined in the Functional RequirementsDocument (FRD). Another purpose is to perform an integrated systemtest function as specified by the design parameters. This function is theresponsibility of the system testers and heavily supported by the userparticipants.

Prerequisites of this phase are the FRD, project management plan andschedule, system baseline software and documents, and a test plancontaining all test requirements and schedules.

Several types of tests are conducted in this phase. First, subsystemintegration tests are executed and evaluated by the development team toprove that the program components integrate properly into thesubsystems and that the subsystems integrate properly into anapplication. Next, the testing team conducts and evaluates system teststo ensure the developed system meets all technical requirements,including performance requirements. Next, the testing team and theSecurity Manager conduct security tests to validate that the access anddata security requirements are met. Finally, users participate inacceptance testing to confirm that the developed system meets all userrequirements as stated in the FRD. Acceptance testing is performed in asimulated real user environment with the users using simulated or realtarget platforms and infrastructures.


The following tasks are completed during the Test Subphase .The test and evaluation team is responsible for establishing the test team

and creating the Test Files/Data.

The test and evaluation team is responsible for creating/loading the testdatabase(s) and executing the system test(s). All results are documentedon the Test Analysis Report, Test Problem Report, and on the TestAnalysis Approval Determination. Any failed components are migratedback to the Development Subphase for rework, and the passed


36/59


components migrated ahead for security testing.

The test and evaluation team create or load the test database(s) andexecute security (penetration) test(s). All tests are documented, similarto those above. Failed components are migrated back to the

Development Subphase for rework, and passed components will bemigrated ahead for acceptance testing.

The test and evaluation team create/load the test database(s) and executethe acceptance test(s). All tests are documented similar to those above.Failed components are migrated back to the Development subphase forrework, and passed components migrate ahead for implementation.

During this phase, the documentation from all previous phases isfinalized to align it with the delivered system. The System Managercoordinates these update activities and is responsible for ensuring thatthe functionality of the systems meets all quality requirements specifiedin the Quality Assurance Plan.

Responsibilities: System Manager: The System Manager is responsible and accountablefor the successful execution of the Test subphase . The System Manageris responsible for leading the team that accomplishes the tasks shownabove.



Gate 3 AUTHORIZ-ATION TOOPERATE:

The purpose of the Authorization to Operate Review is to ensure thatthe system is ready to move into an operational state.

The Authorization to Operate Review is conducted by the designatedapproving authority, who uses the certification package to make adetermination as to the appropriateness of allowing the system tofunction. The system must be accredited for operations prior to the


37/59


system being moved into an operational state. The approving authoritycan provide full authorization to operate or denial of authorization tooperate.

Upon completion of all integration and the Test Subphase tasks and thereceipt of resources for the next phase, the System Manager, togetherwith the project team prepares and presents a project status review forthe SIO, System Sponsor, and other stakeholders. The review shouldaddress:

Test Subphase required work products, which must becomplete, approved, and verified

Planning status for all subsequent life cycle phases (withsignificant detail on the next phase, to include the status of

pending contract actions) Resource availability status

Acquisition risk assessments of subsequent life cycle phasesgiven the planned acquisition strategy

Completion of quality assurance and quality controlactivities for this phase

The final statement of Authorization to Operate is issued by the

Information Management Officer. (IMO)

Work Products:


= Always Required

Work Product StatusChange Directive Change Tracking Log Project Plan USolution Architecture USystem Implementation Plan U


38/59


System Modules (Code, Test, Implementation, and Operational) USystem Test Plan UTest Analysis Approval Determination Summary of the perceived readiness for migration of the software; attached tothe Test Analysis Report as a final result of the test reviews and testing levels

above the integration test.

B

Test Analysis Report BTest Problem Report


39/59


Attachment 3: Implementation Phase

ProcessDescription:

In the Implementation Phase , the system or system modifications areinstalled and made operational in a production environment. The phaseis initiated after the system has been tested and accepted by the user.Activities in this phase include notification of implementation to endusers, execution of the previously defined training plan, data entry orconversion, completion of security certification and accreditation andpost implementation evaluation. This phase continues until the systemis operating in production in accordance with the defined userrequirements.

The new system being implemented can fall into three categories:replacement of a manual process, replacement of a legacy system, orupgrade to an existing system. Regardless of the type of system, allaspects of the implementation phase should be followed. Thisensures the smoothest possible transition to the organizations desiredgoal.


The following activities are performed as part of the ImplementationPhase . A description of these tasks and activities is provided below.

The implementation notice is sent to all users and organizations affectedby the implementation. Additionally, it is good policy to make internal

organizations not directly affected by the implementation aware of theschedule so that allowances can be made for a disruption in the normalactivities of that section. The notice should include:

The schedule of the implementation A brief synopsis of the benefits of the new system The difference between the old and new system Responsibilities of end user affected by the implementation

during this phase The process to obtain system support, including contact names

and phone numbers

Typically, implementation includes converting existing data for use inthe new system. The tasks for this effort are two-fold: data input anddata verification. When replacing a manual system, hard copy data isentered into the automated system. Some sort of verification that thedata is being entered correctly should be conducted throughout thisprocess. This is also the case in data transfer, where data fields in the


40/59


old system may have been entered inconsistently and therefore affect theintegrity of the new database. Verification of the old data becomesimperative to a useful computer system.

One of the ways verification of both system operation and data integritycan be accomplished is through parallel operations. Parallel operationsconsist of running the old process or system and the new systemsimultaneously until the new system is certified. In this way if the newsystem fails in any way, the operation can proceed on the old systemwhile the bugs are worked out.

To ensure that the system is fully operational, install the system in aproduction environment.

After the system has been fielded, a post-implementation evaluation isconducted to determine the success of the project through its

implementation phase. The purpose of this evaluation is to documentimplementation experiences to recommend system enhancements andprovide guidance for future projects.

In addition, Change Implementation Notices are utilized to documentuser requests for fixes to problems that may have been recognizedduring this phase. It is important to document any user request for achange to a system to limit misunderstandings between the end user andthe system programmers.

During this phase, the documentation from all previous phases is

finalized to align it with the delivered system. The System Managercoordinates these update activities.

Responsibilities: System Manager: The System Manager is responsible and accountablefor the successful execution of the Implementation Phase . The SystemManager is responsible for leading the team that accomplishes the tasksshown above and finalizing all of the documentation from previousphases.

Project Team: The project team members (regardless of theorganization of permanent assignment) are responsible foraccomplishing assigned tasks as directed by the System Manager.Oversight Stakeholders: The oversight stakeholders provide oversight,advice and counsel to the System Manager on the conduct andrequirements of the planning effort. Additionally, oversightstakeholders provide information, judgments, and recommendations tothe EPA decision makers during project reviews and in support of


41/59


42/59


Work Product Status

as planned and expected, to verify that the system cost is within theestimated amount, and to verify that the intended benefits are derived asprojected. This report is created at the end of the Implementation Phase.

Project Plan USecurity Certification and AccreditationCertification results in a security assessment report that results in findingsand recommendations. These are used to revise and approve the securityplan any develop any Plans of Action and Milestones (POA&Ms) to correctdeficiencies. The approved security plan, security assessment report andPOA&Ms are components of an Accreditation package. From this theapproving authority will develop the Accreditation which contains theirdecision to accredit, decision rationale and any terms and conditions. Theterm No accreditation signifies identified deficiencies must be correctedbefore the system can move to production/implementation, interimaccreditation allows for implementation based on mission exigencies andrisk acceptance, but does not consider the system accredited for purposes of OMB reporting. Full accreditation allows for implementation in the

production environment. There may be POA&Ms that must be fulfilled,but these do not represent a significant security risk. (see NIST SP 800-37for further details). The Security Accreditation Package includes theCertifiers Statement.

B


System Modules (Code, Test, Implementation, and Operational) BVersion Description DocumentServes as the primary configuration control document used to track andcontrol versions of software released to the operational environment. It is asummary of the features and contents for the software development, andidentifies and describes the version of the software to be delivered.

B


43/59


Attachment 4: Operations & Maintenance Phase

Control Gate # 4 Modify or Terminate

ProcessDescription: More than half of the life cycle cost of a system can be attributed to its

operation and maintenance. In this phase, it is essential that all facets of operation and maintenance are performed. The system is being used andscrutinized to ensure that it meets the needs initially defined duringplanning. Problems may be detected and new needs arise that mayrequire modification to existing code, new code to be developed, and/orhardware configuration changes. Providing user support such asproviding training to new users is an ongoing activity. The emphasis of

this phase is to ensure that the users needs are met and the systemcontinues to perform as specified in the operational environment.Additionally, as operations and maintenance personnel monitor thecurrent system, they may become aware of ways to improve the systemand therefore make recommendations. Changes will be required to fixproblems, possibly add features, and make improvements to the system.This phase continues for as long as the system is in use.


Operations support is an integral part of the day-to-day operation of asystem. In small systems, all or part of each task may be done by thesame person. But in large systems, each function may be done byseparate individuals or even separate areas. The Operations Manual wasdeveloped in previous phases. This document defines tasks, activities,and responsible parties and needs to be updated as changes occur.Systems operations activities and tasks need to be scheduled, on arecurring basis, to ensure that the production environment is fullyfunctional and is performing as specified. The following is a checklist of systems operations key tasks and activities:

Ensure that systems and networks are running and availableduring the defined hours of operation

Ensure all processes, manual and automated, are documentedin the operating procedures. These processes should complywith the system documentation


44/59


Acquisition and storage of supplies, e.g., paper, toner, tapes,removable disks

Perform and test backups (day-to-day protection,contingency)

Perform the physical security functions including ensuringadequate uninterruptible power supply and ensuring thatpersonnel have proper clearances and proper accessprivileges, etc.

Ensure contingency planning for disaster recovery is current,tested, and funded according to the Contingency Plan/COOP

Ensure users are trained on current processes and newprocesses. Provide periodic refresher training and ensurefunding

Ensure that service level objectives are kept accurate and aremonitored

Maintain performance measurements, statistics, and systemlogs. Examples of performance measures include volume andfrequency of data to be processed in each mode, order andtype of operations

Monitor security controls and performance statistics, reportthe results, and escalate problems when they occur

Data/software administration is needed to ensure that input data andoutput data and databases are correct and continually checked foraccuracy and completeness. This includes ensuring that any regularlyscheduled jobs are submitted and completed correctly. Software anddatabases should be maintained at (or near) the current maintenancelevel. The backup and recovery processes for databases are normallydifferent than the day-to-day data/software administration volumebackups. The backup and recovery process of the databases should beperformed as a data/software administration task. A checklist of data/software administration tasks and activities includes the following:

Performing production control and quality control functions(job submission, checking and corrections)

Interfacing with other functional areas for day-to-daychecking/corrections

Installing, configuring, upgrading and maintainingdatabase(s). This includes updating processes, data flows, andobjects (usually shown in diagrams)

Developing and performing data/database backup and


45/59


recovery routines for data integrity and recoverability

Ensuring all processes are properly documented properly inthe Operations Manual

Developing and maintaining a performance plan for onlineprocess and databases

Performing configuration, security and design reviews/auditsto ensure software, system, parameter, and configuration arecorrect

Perform patching of software for the system if and whenrequired

Manage and control configuration and changes to the system

One fact of life with any system is that change is inevitable. Users needan avenue to suggest changes and identified problems. A UserSatisfaction Review which can include a Customer Satisfaction Survey can be designed and distributed to obtain feedback on operationalsystems to help determine if the systems are accurate and reliable .Systems administrators and operators need to be able to makerecommendations for upgrades to hardware, architecture andstreamlining processes. For small in-house systems, modificationrequests can be handled by an in-house process . For large integratedsystems, modification requests may be addressed in the requirementsdocument and may take the form of a change package or a formalChange Implementation Notice and may require justification and costbenefits analysis for approval by a review board. The requirementsdocument for the project may call for a modification cut-off and rolloutof the system as a first version and all subsequent changes addressed as anew or enhanced version of the system. A request for modifications to asystem may also generate a new project and require a new projectinitiation plan.

Daily operations of the system/software may necessitate thatmaintenance personnel identify potential modifications needed to ensurethat the system continues to operate as intended and produces qualitydata. Daily maintenance activities for the system must take place toensure that any previously undetected errors are fixed. Maintenance

personnel may determine that modifications to the system and databasesare needed to resolve errors or performance problems. Also,modifications may be needed to provide new capabilities or to takeadvantage of hardware upgrades or new releases of system software andapplication software used to operate the system. New capabilities maytake the form of routine maintenance or may constitute enhancements tothe system or database as a response to user requests for new/improved


46/59


capabilities. New capability needs may begin a new problemmodification process described above.

At the beginning of this phase any outstanding security-related Plans of Action and Milestones (POA&Ms) must be completed. Throughout the

phase, continuous security monitoring of selected controls must beconducted. In addition, periodic reviews of controls, periodic re-evaluation of information categorization and re-certifications andrevision of risk assessments and security plans, and re-certification andre-authorizations to process (re-accreditation) are conducted as required.Because systems undergo periodic maintenance, enhancements andimprovement, mini life cycles may be required throughout this stage.Continuous vigilance should be given to virus and intruder detection.The System Manager must be sure that security operating procedures arekept updated accordingly.

Review and update system documentation including the operations fromthe previous phases. In particular, the Operations Manual, BusinessCase, and Contingency Plan/COOP (including results of tests during thisphase), as required, need to be updated and finalized during theOperations and Maintenance Phase . The System Manager must reporton any security incidents related to the system during this phase.

Responsibilities: System Manager: The System Manager develops documents andexecutes plans and procedures for conducting activities and tasks of the

maintenance period and conducts quality assurance activities on thosedocuments. To provide for an avenue of problem reporting and customersatisfaction, the Systems Manager should create and discusscommunications instructions with the systems customers. SystemsManagers should keep the Help Desk personnel informed of all changesto the system especially those requiring new instructions to users, andmust report on all security incidents.

Technical Support: Personnel which provide technical support to theprogram. This support may involve granting access rights to theprogram, setup of workstations or terminals to access the system, andmaintenance of the operating system for both server and workstation.Technical support personnel may be involved with issuing user IDs orlogin names and passwords. In a client-server environment, technicalsupport may perform systems scheduled backups and operating systemmaintenance during downtime.

Vendor Support: The technical support and maintenance on someprograms are provided through vendor support. A contract is establishedoutlining the contracted systems administration, operators, and


47/59


maintenance personnel duties and responsibilities. One responsibilitywhich should be included in the contract is that all changes to the systemwill be thoroughly documented.

Help Desk: Help Desk personnel provide the day-to-day users help for

the system. Help desk personnel should be kept informed of all changesor modifications to the system. Help Desk personnel are contacted bythe user when questions or problems occur with the daily operations of the system. Help Desk personnel need to maintain a level of proficiencywith the system.

Operations or Operators (turn on/off systems, start tasks, backupetc): For many mainframe systems, an operator provides technicalsupport for a program. The operator performs scheduled backup,performs maintenance during downtime and is responsible to ensure thesystem is online and available for users. Operators may be involvedwith issuing user IDs or login names and passwords for the system.

Customers: The customer needs to be able to share with the systemsmanager the need for improvements or the existence of problems. Someusers live with a situation or problem because they feel they must.Customers may feel that change will be slow or disruptive. Some feelthe need to create work-arounds. A customer has the responsibility toreport problems or make recommendations for changes to a system.

Program Analysts or Programmer: Interprets user requirements,designs and writes the code for specialized programs. User changes,improvements, enhancements may be discussed in Joint ApplicationDesign sessions. Analyzes programs for errors, debugs the program andtests program design.Process Improvement Review Board: A board of individuals may beconvened to approve recommendations for changes and improvements tothe system. This group may be chartered. The charter should outlinewhat should be brought before the group for consideration and approval.The board may issue a Change Directive.

Users Group or Team: A group of computer users who shareknowledge they have gained concerning a program or system. Theyusually meet to exchange information, share programs and can provideexpert knowledge for a system under consideration for change.

Contract Manager : The Contract Manager has many responsibilitieswhen a contract has been awarded for maintenance of a program. TheContract Manager should have a certificate of training for completion of a Contracting Officers Technical Representative (COTR) course. TheContract Managers main role is to make sure that the interests of theProcurement Office are protected and that no modifications are made to


48/59


the contract without permission from the Procurement Office.

Data Administrator: Performs tasks which ensure that accurate andvalid data are entered into the system. Sometimes this person creates theinformation systems database, maintains the databases security and

develops plans for disaster recovery. The data administrator may becalled upon to create queries and reports for a variety of user requests.The data administrator responsibilities include maintaining the databasesdata dictionary. The data dictionary provides a description of each fieldin the database, the field characteristics and what data is maintained withthe field.

Telecommunications Analyst and Network System Analyst: Plans,installs, configures, upgrades, and maintains networks as needed. If thesystem requires it, they ensure that external communications andconnectivity are available.

Information Security Officer (ISO): The ISO has a requirement toreview system change requests, review and in some cases coordinate theChange Impact Assessments, participate in the Configuration ControlBoard process, and conduct and report changes that may be made thataffect the security posture of the system. The ISO is also responsible forensuring that all POA&Ms are tracked appropriately.

Gate 4 MODIFY ORTERMINATEREVIEW:

The purpose of the Modify or Terminate Review is to determine if the ITInvestment should continue, be modified or terminated.

The Modify or Terminate Review is coordinated by OEI, who ensures theIT Investment Business Case is accurate and complete. The package isthen forwarded to the QIC, who relies on the IIS to provide a throughBusiness Case review in accordance with the EPAs CPIC EvaluationPhase criteria, determining if it can optimally continue to supportmission/user requirements and the EPAs strategic direction. The IISdevelops recommendations for the QIC to make a decision on whether tokeep this investment as part of the EPAs IT Investment Portfolio as is,modify or terminate the investment.

Review activities occur several times throughout this phase. Each time

the system is revi