AQS-200 SDLC Work Instruction - Federal Aviation ... · Web viewCircular A-11, Part 3, Planning, Budgeting, and Acquisition of Capital Assets, also requires the submission of Exhibit

AVSQuality Management System

QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page 1 of 351

AQS-200-001-WI

AQS-200 System Development Life Cycle

Purpose & Scope

This document was prepared to provide guidance for AQS-200 Information Technology Division personnel in the accomplishment of certain agency responsibilities. The guidance in this document relates to enterprise software development projects that are the responsibility of the AQS-200 division. It provides guidance to AQS-200 systems development project staff and managers, as well as to AVS services (AIR, AFS, AAI, etc) for their application development efforts.

This work instruction is linked to the AVS-200-001 Design and Development Control Process and the AQS-200-001 WI 4, Program/Project Management Plan Development and Maintenance work instruction. These three documents are used in conjunction to develop program management plans for the management and control of AVS/AQS projects. Please note that this document contains the highest level of detail in terms of deliverables and documentation. This level of detail will not be required by all projects; the deliverables and lifecycle choices outlined in the program management plan supersede to those presented in this document.

This work instruction is a reference text to be used as guidance in the development and updating of program management plans and the subsequent management of projects. It is expected that sections will be periodically referenced through the life of a project. Please note that the terms “Program Manager” and “Project Manager” are used interchangeably throughout this document.

Approval: < signed by JoAnn Carroll > Date: 2/5/07

Information Technology Division//

UNCONTROLLED COPY WHEN DOWNLOADEDCheck The Master List To Verify That This Is The Correct Revision Before Use


QPM #

AQS 200-001-WI

Revision

1


REVISION HISTORY

Rev Description of Change Effective Date

0Original

Formatted to comply with the AVS process template and link to the AQS-200-001 process

06/28/06

1 Updated to reference AQS-200-001 WI 4, Process Lifecycle Process and explicitly state that it is guidance

2/5/07



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page i of 351

TABLE OF CONTENTS

0 Executive Summary.........................................................................................................10.1. The System Development Life Cycle.....................................................................1

0.2. Purpose, Scope, and Applicability..........................................................................1

0.3. SDLC Benefits........................................................................................................1

0.4. Key Principles........................................................................................................2

1 Introduction......................................................................................................................51.1. Background............................................................................................................5

1.2. Purpose, Scope, and Applicability..........................................................................5

1.3. Introduction to SDLC..............................................................................................6

1.4. Controls/Assumptions............................................................................................9

1.5. Documentation.......................................................................................................9

2 Strategic Planning for Information Systems...............................................................112.1. Strategic Planning................................................................................................11

2.2. IRM Planning for Information Systems.................................................................11

2.3. Performance Measurement..................................................................................11

2.4. Business Process Reengineering........................................................................12

2.5. Quality Improvement Process and the Life Cycle................................................13

2.6. Budget Formulation for Systems Initiatives..........................................................13

3 Key Supporting Processes...........................................................................................153.1. Objective..............................................................................................................15

3.2. Project Planning...................................................................................................15

3.3. Requirements Management.................................................................................28

3.4. Project Tracking and Oversight............................................................................32

3.5. Contractor Management......................................................................................37

3.6. Validation, Verification, and Testing.....................................................................39

3.7. Quality Assurance................................................................................................42

3.8. Configuration Management..................................................................................43

3.9. Risk Management................................................................................................45

4 Phase 1: System Concept Development Phase..........................................................49



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page ii of 351

4.1. Objectives............................................................................................................49

4.2. Tasks and Activities.............................................................................................50

4.3. Roles and Responsibilities...................................................................................52

4.4. Deliverables, Responsibilities, and Actions..........................................................52

4.5. Issues for Consideration......................................................................................53

4.6. Review Activity.....................................................................................................55

5 Phase 2: Planning Phase..............................................................................................565.1. Objective..............................................................................................................56





5.6. Review Activity.....................................................................................................61

6 Phase 3: Requirements Analysis Phase......................................................................626.1. Objective..............................................................................................................62





6.6. Review Activity.....................................................................................................68

7 Phase 4: Design Phase..................................................................................................697.1. Objective..............................................................................................................69





7.6. Review Activity.....................................................................................................75

8 Phase 5: Development Phase.......................................................................................778.1. Objective..............................................................................................................77



8.4. Deliverables, Responsibilities and Actions...........................................................84UNCONTROLLED COPY WHEN DOWNLOADED

Check The Master List To Verify That This Is The Correct Revision Before Use


QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page iii of 351


8.6. Review Activity.....................................................................................................85

9 Phase 6: Integration and Test Phase...........................................................................869.1. Objective..............................................................................................................86





9.6. Review Activity.....................................................................................................89

10 Phase 7: Implementation Phase...................................................................................9010.1. Objective..............................................................................................................90





10.6. Review Activity.....................................................................................................93

11 Phase 8: Operations and Maintenance Phase............................................................9511.1. Objective..............................................................................................................95



11.4. Deliverables, Responsibilities and Action............................................................99


11.6. Review Activity...................................................................................................100

12 Phase 9: Disposition Phase........................................................................................10112.1. Objective............................................................................................................101

12.2. Tasks and Activities...........................................................................................101

12.3. Roles and Responsibilities.................................................................................102

12.4. Deliveables, Responsibilities and Action............................................................103

12.5. Issues for Consideration....................................................................................103

12.6. Review Activity...................................................................................................103

13 Alternative SDLC Work Patterns................................................................................10313.1. Objective............................................................................................................103



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page iv of 351

13.2. Alternative Work Patterns..................................................................................103

13.3. Alternative Work Pattern Selection....................................................................103

13.4. Work Pattern Descriptions and Exhibits.............................................................103

13.5. Additional Work Patterns....................................................................................103

14 System Boundary Document......................................................................................10314.1. Format for SBD Cover Memo.............................................................................103

14.2. The Requirements Document............................................................................103

14.3. Traceability.........................................................................................................103

14.4. Approval.............................................................................................................103

14.5. Using This Template..........................................................................................103

14.6. AQS-200-Controlled Parameters.......................................................................103

14.7. Change Control..................................................................................................103

14.8. Cost....................................................................................................................103

14.9. Schedule............................................................................................................103

14.10. Benefits..............................................................................................................103

14.11. Examples of Operational and Functional Requirements....................................103

14.12. Examples of Characteristics and Performance Requirements...........................103

14.13. References.........................................................................................................103

15 Cost-Benefit Analysis..................................................................................................10315.1. Overview............................................................................................................103

15.2. Objectives and Performance Measures.............................................................103

15.3. Assumptions, Constraints, and Conditions........................................................103

15.4. Feasible Alternatives..........................................................................................103

15.5. Cost Analysis.....................................................................................................103

15.6. Benefit Analysis..................................................................................................103

15.7. Comparison of Costs and Benefits.....................................................................103

15.8. Sensitivity Analysis.............................................................................................103

15.9. Results of the Analysis.......................................................................................103

15.10. References and Documentation.........................................................................103

15.11. Glossary and Acronyms.....................................................................................103

15.12. Cost-Benefit Analysis Outline.............................................................................103

16 Feasibility Study..........................................................................................................103UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page v of 351

16.1. Introduction........................................................................................................103

16.2. Evaluation Criteria..............................................................................................103

16.3. Alternative Descriptions.....................................................................................103

16.4. Alternative Evaluation........................................................................................103

16.5. Recommendation...............................................................................................103

16.6. Feasibility Study Outline.....................................................................................103

17 Risk Management Plan................................................................................................10317.1. Introduction........................................................................................................103

17.2. Risk Identification List........................................................................................103

17.3. Risk Assessment................................................................................................103

17.4. Risk Action Plan.................................................................................................103

17.5. Risk Management Outline..................................................................................103

18 Acquisition Plan...........................................................................................................10318.1. Background and Objectives...............................................................................103

18.2. Plan of Action.....................................................................................................103

18.3. Acquisition Plan Outline.....................................................................................103

19 Configuration Management Plan................................................................................10319.1. Introduction........................................................................................................103

19.2. Organization.......................................................................................................103

19.3. Configuration Identification.................................................................................103

19.4. Configuration Control.........................................................................................103

19.5. Configuration Status Accounting........................................................................103

19.6. Configuration Audits...........................................................................................103

19.7. Reviews..............................................................................................................103

19.8. CM Plan Maintenance........................................................................................103

19.9. Data Management..............................................................................................103

19.10. Subcontractor Control........................................................................................103

19.11. Configuration Management Plan Outline...........................................................103

20 Quality Assurance Plan...............................................................................................10320.1. General..............................................................................................................103

20.2. Organization.......................................................................................................103

20.3. Processes..........................................................................................................103UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page vi of 351

20.4. Problem Reporting and Corrective Action..........................................................103

20.5. Tools, Techniques, and Methodologies.............................................................103

20.6. Quality Assurance Plan Outline.........................................................................103

21 Concept of Operations................................................................................................10321.1. Statement of Need.............................................................................................103

21.2. Organizational Units Impacted (Customers)......................................................103

21.3. Work to be Automated.......................................................................................103

21.4. Costs and Benefits.............................................................................................103

21.5. Options Considered...........................................................................................103

21.6. How the Function is Currently Performed..........................................................103

21.7. Requester’s Name, Routing Symbol and Position.............................................103

21.8. Concept Paper...................................................................................................103

22 System Security Plan..................................................................................................10323 Project Management Plan...........................................................................................103

23.1. Introduction........................................................................................................103

23.2. Project Description.............................................................................................103

23.3. Project Background............................................................................................103

23.4. Points of Contact................................................................................................103

23.5. Project References.............................................................................................103

23.6. Glossary.............................................................................................................103

23.7. Organization And Responsibilities.....................................................................103

23.8. Project Description, Schedule and Resources...................................................103

23.9. Security and Privacy..........................................................................................103

23.10. Project Management Plan Outline.....................................................................103

24 Verification and Validation Plan.................................................................................10324.1. Background and Introduction.............................................................................103

24.2. V&V Requirements and Measurement Criteria..................................................103

24.3. Phase by Phase V&V Plans...............................................................................103

24.4. Verification and Validation Plan Outline.............................................................103

25 Systems Engineering Management Plan...................................................................10325.1. Introduction........................................................................................................103

25.2. System Engineering Process.............................................................................103UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page vii of 351

25.3. Technology Refreshment...................................................................................103

25.4. Implementation Planning....................................................................................103

25.5. Specialty Engineering Planning.........................................................................103

25.6. Systems Engineering Management Plan Outline...............................................103

26 Functional Requirements Document.........................................................................10326.1. Introduction........................................................................................................103

26.2. Functional Requirements...................................................................................103

26.3. Operational Requirements.................................................................................103

26.4. Requirements Traceability Matrix.......................................................................103

26.5. Glossary.............................................................................................................103

26.6. Functional Requirements Document Outline.....................................................103

27 Test and Evaluation Master Plan................................................................................10327.1. Introduction........................................................................................................103

27.2. Purpose..............................................................................................................103

27.3. Background........................................................................................................103

27.4. Scope.................................................................................................................103

27.5. Glossary.............................................................................................................103

27.6. Limitations and Traceability................................................................................103

27.7. Test Plans..........................................................................................................103

27.8. Test Description.................................................................................................103

27.9. Test and Evaluation Master Plan Outline...........................................................103

28 Interface Control Document........................................................................................10328.1. Scope.................................................................................................................103

28.2. System Identification..........................................................................................103

28.3. Document Overview...........................................................................................103

28.4. Applicable Documents.......................................................................................103

28.5. Description.........................................................................................................103

28.6. Detailed Interface Requirements........................................................................103

28.7. Qualification Methods.........................................................................................103

28.8. Notes..................................................................................................................103

28.9. Appendices........................................................................................................103

28.10. Approvals...........................................................................................................103UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page viii of 351

28.11. Record of Changes............................................................................................103

28.12. Interface Control Document Outline...................................................................103

29 Security Risk Assessment..........................................................................................10330 Contingency Plan.........................................................................................................10331 Conversion Plan...........................................................................................................103

31.1. Introduction........................................................................................................103

31.2. Conversion Overview.........................................................................................103

31.3. Conversion Support...........................................................................................103

31.4. Conversion Plan Outline....................................................................................103

32 System Design Document...........................................................................................10332.1. Introduction........................................................................................................103

32.2. System Architecture...........................................................................................103

32.3. File and Database Design..................................................................................103

32.4. Human-Machine Interface..................................................................................103

32.5. Detailed Design..................................................................................................103

32.6. External Interfaces.............................................................................................103

32.7. System Integrity Controls...................................................................................103

32.8. Design Document Outline..................................................................................103

33 Implementation Plan....................................................................................................10333.1. Introduction........................................................................................................103

33.2. Management Overview......................................................................................103

33.3. Implementation Support.....................................................................................103

33.4. Implementation Requirements by Site...............................................................103

33.5. Implementation Plan Outline..............................................................................103

34 Maintenance Manual....................................................................................................10334.1. Introduction........................................................................................................103

34.2. System Description............................................................................................103

34.3. Support Environment.........................................................................................103

34.4. System Maintenance Procedures......................................................................103

34.5. Software Unit Maintenance Procedures.............................................................103

34.6. Maintenance Manual Outline.............................................................................103

35 Operations Manual.......................................................................................................103UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page ix of 351

35.1. General..............................................................................................................103

35.2. System Overview...............................................................................................103

35.3. Description of Runs............................................................................................103

35.4. Operations Manual Outline................................................................................103

36 System Administration Manual..................................................................................10336.1. General..............................................................................................................103

36.2. System Overview...............................................................................................103

36.3. Site Profile(s)......................................................................................................103

36.4. Systems Administration......................................................................................103

36.5. Systems Administration Manual Outline............................................................103

37 Training Plan................................................................................................................10337.1. Introduction........................................................................................................103

37.2. Requirements Traceability.................................................................................103

37.3. Instructional Analysis.........................................................................................103

37.4. Instructional Methods.........................................................................................103

37.5. Training Resources............................................................................................103

37.6. Training Curriculum............................................................................................103

37.7. Training Plan Outline..........................................................................................103

38 User Manual..................................................................................................................10338.1. Introduction........................................................................................................103

38.2. System Capabilities............................................................................................103

38.3. Description of System Functions........................................................................103

38.4. Operating Instructions........................................................................................103

38.5. Error Handling....................................................................................................103

38.6. User Manual Outline..........................................................................................103

39 Software development Document..............................................................................10339.1. 1.0 Introduction..................................................................................................103

39.2. 2.0 Roles and Responsibilities...........................................................................103

39.3. Software Development Folder Check-Off Sheet................................................103

40 Integration Document..................................................................................................10340.1. Introduction........................................................................................................103

40.2. Management Overview......................................................................................103UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page x of 351

40.3. Integration Support.............................................................................................103

40.4. Integration Document Outline............................................................................103

41 Test Analysis Report...................................................................................................10341.1. Purpose..............................................................................................................103

41.2. Scope.................................................................................................................103

41.3. Reference Documents.......................................................................................103

41.4. Test Analysis......................................................................................................103

41.5. Software and Hardware Requirements Findings...............................................103

41.6. Summary and Conclusions................................................................................103

41.7. Test Analysis Report Outline..............................................................................103

42 Test Analysis Approval Determination......................................................................10342.1. Test Analysis Approval Determination Outline (Non-Mainframes )....................103

42.2. Test Analysis Approval Determination (For Mainframes)...................................103

43 Test Problem Reports..................................................................................................10343.1. Test Problem Report Outline..............................................................................103

44 Change Implementation Notice..................................................................................10345 Version Description Document..................................................................................103

45.1. Introduction........................................................................................................103

45.2. Scope.................................................................................................................103

45.3. Reference Documents.......................................................................................103

45.4. Version Description............................................................................................103

45.5. Appendices........................................................................................................103

45.6. Version Description Document Outline..............................................................103

45.7. Version Description Document Contents...........................................................103

46 Post-Implementation Review Report.........................................................................10346.1. Introduction........................................................................................................103

46.2. Evaluation Summary..........................................................................................103

46.3. Analysis and Implementation.............................................................................103

46.4. Outputs...............................................................................................................103

46.5. Security..............................................................................................................103

46.6. Computer Operations.........................................................................................103

46.7. Maintenance Activities.......................................................................................103UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1

Title: System Development Lifecycle Date: 2/5/07 Page xi of 351

46.8. Post-implementation Review Report Outline.....................................................103

47 Periodic System Review Report.................................................................................10347.1. Introduction........................................................................................................103

47.2. Review Process.................................................................................................103

47.3. Findings..............................................................................................................103

47.4. Recommendations.............................................................................................103

47.5. Approvals and Appendices................................................................................103

47.6. Periodic System Review Report Outline............................................................103

48 User Satisfaction Review............................................................................................10348.1. Introduction........................................................................................................103

48.2. Roles and Responsibilities.................................................................................103

48.3. Process..............................................................................................................103

48.4. User Satisfaction Review Outline.......................................................................103

49 Disposition Plan...........................................................................................................10349.1. Introduction........................................................................................................103

49.2. System Disposition.............................................................................................103

49.3. Project Closedown.............................................................................................103

49.4. Disposition Plan Outline.....................................................................................103

50 Post-Termination Review Report...............................................................................10350.1. Introduction........................................................................................................103

50.2. Lessons Learned................................................................................................103

50.3. Archiving............................................................................................................103

50.4. Post-Termination Review Report Outline...........................................................103

51 Information Security Requirements...........................................................................10352 Glossary........................................................................................................................10353 Acronyms.......................................................................................................................103



QPM #

AQS 200-001-WI

Revision

1


0 EXECUTIVE SUMMARY

0.1. THE SYSTEM DEVELOPMENT LIFE CYCLEThe primary objectives of any SDLC are to deliver quality systems that: 1) meet or exceed customer expectations when promised and within cost estimates, 2) work effectively and efficiently within the current and planned information technology infrastructure, and 3) are inexpensive to maintain and cost-effective to enhance. This SDLC establishes a logical order of events for conducting system development that is controlled, measured, documented, and ultimately improved. The System Development Life Cycle (SDLC) emphasizes decision processes that influence system cost and usefulness. These decisions must be based on full consideration of business processes, functional requirements, and economic and technical feasibility in order to produce an effective system.

This document does not prescribe a single lifecycle method applicable without change to every system. Because there is wide variance in the methods, techniques and tools used to support the evolution of systems, and project scopes vary greatly, the SDLC presents guidance for selecting appropriate methods, techniques, and tools based on specific factors.

One methodology does not fit all sizes and types of system development efforts. Therefore, the AVS SDLC methodology provides for a full sequential SDLC work pattern and for alternative SDLC work patterns. Components involved in smaller projects could use these alternative SDLC work patterns, where the documentation is shortened and even combined. It also provides a work pattern to accommodate the acquisition and implementation of commercial-off-the-shelf (COTS) products. These alternatives were borrowed from the Department of Justice (DOJ) SDLC, dated June 18, 1999.

0.2. PURPOSE, SCOPE, AND APPLICABILITYThe SDLC serves as the mechanism to assure that systems under development meet the established requirements and support AVS mission functions. It provides a structured approach to managing information technology (IT) projects beginning with establishing the justification for initiating a systems development or maintenance effort, and concluding with system disposition. Examples of documentation outlines are included in beginning in Section 13.

The primary audiences for this guidance are those responsible for defining and delivering AVS systems: system developers, project managers, program and account analysts, system owners and users, their staff, and their support contractors. Specific roles and responsibilities are described throughout this document for each life cycle phase.

0.3. SDLC BENEFITSThis guide was developed to disseminate proven practices to system developers, project managers, program and account analysts, system owners and users throughout the AVS. The specific benefits expected include the following:

Reduced risk of project failure; Consideration of system and data requirements throughout the entire life of the

system; Early identification of technical and management issues;



QPM #

AQS 200-001-WI

Revision

1


Disclosure of all life cycle costs to guide business decisions; Fostering realistic expectations of what the systems will and will not provide; Information to better balance programmatic, technical, management, and cost

aspects of proposed system development or modification; Encouragement of periodic evaluations to identify systems that are no longer

effective; Measurements of progress and status to enable effective corrective action; Information that supports effective resource management and budget planning; Consideration of meeting current and future business requirements.

0.4. KEY PRINCIPLESThis guidance document refines traditional information system life cycle management approaches to reflect the principles outlined in the following subsections. These are the foundations for life cycle management.

1. Life cycle management should be used to ensure a structured approach to information systems development, maintenance, and operation.

This SDLC describes an overall structured approach to information management. Primary emphasis is placed on the information and systems decisions to be made and the proper timing of decisions. The manual provides a flexible framework for approaching a variety of systems projects. The framework enables system developers, project managers, program and account analysts, system owners, and users to combine activities, processes, and products, as appropriate, and to select the tools and methodologies best suited to the unique needs of each project.

2. The SDLC should support the use of a project Change Control Board.

The establishment of a project Change Control Board (CCB) can aid in the success of a project. A CCB is a multidisciplinary group of people who support the Project Manager in the planning, execution, delivery and implementation of life cycle decisions for the project. The CCB is composed of qualified empowered individuals from all appropriate functional disciplines that have a stake in the success of the project. Working together in a proactive, open communication, team-oriented environment can aid in building a successful project and providing decision makers with the necessary information to make the right decisions at the right time.

3. Each system project must have a Business Sponsor.

To help ensure effective planning, management, and commitment to information systems, each project must have a clearly identified business sponsor. The business sponsor serves in a leadership role, providing guidance to the project team and securing, from senior management, the required reviews and approvals at specific points in the life cycle. An approval from senior management is required after the completion of the first seven of the SDLC phases, annually during Operations and Maintenance Phase and six-months after the Disposition Phase. Senior management approval authority may be varied based on dollar value, visibility level, congressional interests or a combination of these. The business sponsor organization is responsible for identifying who will be



QPM #

AQS 200-001-WI

Revision

1


responsible for formally accepting the delivered system at the end of the Implementation Phase.

4. A single Project Manager must be selected for each system/software project.

The Project Manager has responsibility for the success of the project and works through a project team and other supporting organization structures, such as working groups or user groups, to accomplish the objectives of the project. Regardless of organizational affiliation, the Project Manager is accountable and responsible for ensuring that project activities and decisions consider the needs of all organizations that will be affected by the system. The Project Manager develops a project charter to define and clearly identify the lines of authority between and within the agency's executive management, project proponent, user/customer, and developer for purposes of management and oversight.

5. A Software Project Management Plan is required for each project.

The Software Project Management Plan (SPMP) is a pivotal element in the successful solution of an information management requirement. The SPMP must describe how each life cycle phase will be accomplished to suit the specific characteristics of the project. The SPMP is a vehicle for documenting the project scope, tasks, schedule, allocated resources, and interrelationships with other projects. The plan is used to provide direction to the many activities of the life cycle and must be refined and expanded throughout the life cycle.

6. Specific individuals must be assigned to perform key roles throughout the life cycle.

Certain roles are considered vital to a successful system project and at least one individual must be designated as responsible for each key role. Assignments may be made on a full- or part-time basis as appropriate. Key roles include program/functional management, quality assurance, security, telecommunications management, data administration, database administration, logistics, financial, systems engineering, test and evaluation, contracts management, and configuration management. For most projects, more than one individual should represent the actual or potential users of the system (that is, program staff) and should be designated by the Program Manager of the proponent program and organization.

7. Obtaining the participation of skilled individuals is vital to the success of the project.

The skills of the individuals participating in a project are the single most significant factor for ensuring success. The SDLC manual is not intended as a substitute for information management skills or experience. While many of the skills required for a project are discussed in later sections, the required skill combination will vary according to the project. All individuals participating in a development project are encouraged to obtain assistance from experienced information management professionals.

8. Documentation of activity results and decisions for each life cycle phase is essential.

Effective communication and coordination of activities throughout the life cycle depend on the complete and accurate documentation of decisions and the events leading up to them. Undocumented or poorly documented events and decisions can cause significant confusion or wasted efforts and can intensify the effect of turnover of project management staff. Activities should not be considered complete, nor decisions made,



QPM #

AQS 200-001-WI

Revision

1


until there is tangible documentation of the activity or decision. For some large projects, advancement to the next phase cannot commence until the required reviews are completed and approved by senior management.

9. Data management is required throughout the life cycle.

AVS considers the data processed by systems to be an extremely valuable resource. Accurate and accessible data is critical to support organizational missions. The large volumes of data handled by AVS (and its components), as well as the increasing trend towards interfacing and sharing data across systems and programs, underscores the importance of data quality. Systems life cycle activities stress the need for clear definition of data, and the design and implementation of automated and manual processes that ensure effective data management.

10. Each project must undergo formal acceptance.

The business sponsor identifies the representative who will be responsible for formally accepting the delivered project at the end of the Implementation Phase. The project is formally accepted by the proponent organization representative by signing an Implementation Phase Review and Approval Certification along with the developer.

11. Consultation with oversight organizations aids in the success of a project.

A number of AVS oversight bodies, as well as external organizations, have responsibility for ensuring that information technology activities are performed in accordance with AVS/Federal guidance and standards and available resources are used effectively. Each project team should work with these organizations, as appropriate, and encourage their participation and support as early as possible in the life cycle to identify and resolve potential issues or sensitivities and thereby avoid major disruptions to the project. Assume all documentation is subject to review by oversight activities.

12. A project may not proceed until resource availability is assured

Commitment from the business sponsor to follow the SDLC is important. This commitment is embodied in the assurance that the necessary resources will be available, not only for the next activity, but as required for the entire life cycle.

13. Each project should comply with the AVS Enterprise Architecture.

The Enterprise Architecture (EA) provides a common conceptual framework and overarching Reference Models that all AVS organizations can use to coordinate the acquisition, development, and support of information systems. The Reference Models and architectural objectives advance AVS’ ability to implement systems that are more interoperable and maintainable.

14. Each project should incorporate information security at the earliest point possible.

As use of the Internet becomes a critical part of AVS’ IT strategy, incorporating information security features into IT systems has become a necessary part of that strategy. AVS has developed information security requirements and guidelines that are available to project managers and staff, and this SDLC fosters use of those documents.



QPM #

AQS 200-001-WI

Revision

1


1 INTRODUCTION

0.5. BACKGROUNDAVS spends millions of dollars each year on the acquisition, design, development, implementation, and maintenance of information systems vital to mission programs and administrative functions. The need for safe, secure, and reliable system solutions is heightened by the increasing dependence on computer systems and technology to provide services and develop products, administer daily activities, and perform short- and long-term 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.

AVS needs a systematic and uniform methodology for information systems development. This methodology will be Institute of Electrical and Electronics Engineers/Electronic Industries Association (IEEE/EIA) and International Standard Organization (ISO) standard compliant and addresses the Software Capability Maturity Model (SW-CMM) requirements. CMM is a mechanism that ranks a potential contractor's software maturity. Using this SDLC will ensure that systems developed by AVS meet IT mission objectives and are easy to maintain and cost-effective to enhance. Sound life cycle management practices include planning and evaluation in each phase of the information system life cycle. The appropriate level of planning and evaluation is commensurate with the cost of the system, the stability and maturity of the technology under consideration, how well defined the user requirements are, the level of stability of program and user requirements, and security considerations.

0.6. PURPOSE, SCOPE, AND APPLICABILITY0.6.1. PurposeThis SDLC methodology establishes procedures, practices, and guidelines governing the concept development; planning; requirements analysis; design; development; integration and test; implementation; and operations, maintenance and disposition of information systems within AVS. It should be used in conjunction with existing policy and guidelines for acquisition and procurement, as these areas are not discussed in the SDLC.

0.6.2. ScopeThis methodology should be used for all AVS information systems and applications. It is applicable across all information technology (IT) environments (e.g., mainframe, client, and server) and applies to contractually-developed as well as in-house developed applications. The specific participants in the life cycle process, and the necessary reviews and approvals, vary from project to project. The guidance provided in this document should be tailored to the individual project based on cost, complexity, and criticality to the agency's mission. See Section 13 for Alternate SDLC Work Patterns if a formal SDLC is not feasible. Similarly, the documents called for in the guidance and shown in Section 13 and subsequent sections should be tailored based on the scope of the effort and the needs of the decision authorities.



QPM #

AQS 200-001-WI

Revision

1


0.6.3. ApplicabilityThis methodology can be applied to all AVS offices that are responsible for information systems development.

0.6.4. ReferencesStandard for Information Technology — Software life cycle processes – IEEE Standard 12207.0-2 dated 1996.

0.7. INTRODUCTION TO SDLCThe SDLC includes nine phases during which defined project work products are created or modified. The ninth phase occurs when the system is disposed of and the task performed by the system is either eliminated or transferred to other systems. The tasks and work products for each phase are described in subsequent chapters. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap, as shown in Figure 1-1 and Figure 1-2.

FIGURE 1-1: SYSTEM DEVELOPMENT LIFE CYCLE PHASES

System Development

Concept Phase

Begins when a sponsor identifies a need or an opportunity to develop, enhance, or acquire and information system. Defines the requirement or opportunity, linking it to specific enterprise missions. Includes a feasibility study and cost benefit analysis. May result in the initiation of a project.

Planning Phase

Establishes a comprehensive model of the recommended approach to provide better project definition. Addresses the concept identified in the Concept Development Phase, providing the basis for acquiring the resources needed to achieve a solution. Develops a project plan and other planning documents.

Requirements Analysis Phase

Analyzes user needs and develops user requirements. Creates a detailed functional requirements document. Defines inputs, processes, and outputs. Focuses on what functions must be delivered rather than how to deliver them. Serves as the basis for the initial test and QA plans.

Design Phase

Transforms detailed requirements definitions into complete, details system specifications. Focuses on how to deliver the required functionality. Develops an internal and external design. Also includes creation of the maintenance, user, and operator manual and the training, conversion, and contingency plans.

Development Phase

Converts a design into a complete information system. Includes the following activities: acquire and install systems environment, create and test databases, prepare test case procedures, prepare test files, code, compile, refine programs, perform test readiness review and procurement activities.



QPM #

AQS 200-001-WI

Revision

1


Integration and Test Phase

Demonstrates that the developed system conforms to requirements as specified in the functional requirements document. Conducted by the QM staff and users. Produces test analysis reports.

Implementation Phase

Includes implementation preparation, implementation of the system into a production environment, and resolution of problems identified in the implementation.

Operation and Maintenance

Phase

Describes tasks for the maintenance and operation of information systems in a production environment. Includes post-implementation and periodic reviews.

Disposition Phase

Describes end-of-life system activities. Emphasis is given to proper preservation of data.

FIGURE 1-2: PHASE INTERACTION



QPM #

AQS 200-001-WI

Revision

1


Figure 1-2: Phase Interaction shows the relationship among the life cycle phases. Strategic Planning leads to System Concept Development Phase, which leads to the Planning Phase, Requirements Analysis Phase, Design Phase, Development Phase, Integration and Test Phase, Implementation Phase, Operations and Maintenance Phase and Disposition Phase. All are linked to a systems project.

0.7.1. System Concept Development PhaseSystem (or project) concept development actually starts the life cycle when a need to develop or significantly change a system is identified. Once a business need, based on operational requirements, is identified and documented, the approaches for meeting it are reviewed for feasibility and appropriateness. The need may involve development of a new system or modification of an existing system. Senior Official approvals and funding are needed before beginning the Planning Phase.

0.7.2. Planning PhaseA program management plan is developed that documents the approach to be used and includes the discussion of methods, tools, tasks, resources, project schedules, and user input.

0.7.3. Requirements Analysis PhaseFunctional user requirements are formally defined and delineate the requirements in terms of data, system performance, security, and maintainability requirements for the system. All requirements are defined to a level of detail sufficient for systems design to proceed.

0.7.4. Design PhaseThe external physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval must be documented and reviewed by the user. The internal physical characteristics of the system are specified and a detailed design is prepared. Subsystems defined during the external design are used to create a detailed structure of the system. Each subsystem is partitioned into one or more design units or modules. Detailed logic specifications are prepared for each software module.

0.7.5. Development PhaseThe detailed specifications produced during the design phase are translated into hardware, communications, and executable software. Software is unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested.

0.7.6. Integration and Test PhaseSubsystem integration, system, security, and user acceptance testing is conducted during the integration and test phase. The user, with the quality assurance organization, validates that the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system.



QPM #

AQS 200-001-WI

Revision

1


0.7.7. Implementation PhaseThe system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements.

0.7.8. Operations and Maintenance PhaseThe system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and needed system modifications are incorporated. Operations continue as long as the system can be effectively adapted to respond to an organization's needs. When modifications or changes are identified as necessary, the system may reenter the planning phase.

0.7.9. Disposition PhaseThe disposition activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the system, so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.

0.8. CONTROLS/ASSUMPTIONS

The AVS Office of the CIO recognizes the need for a strategy-driven, forward-looking and collaboratively managed enterprise-level architectural model for its IT infrastructure. AVS national-level programs need to work within a framework in which the enabling technologies underlying the infrastructure can deliver secure and interoperable mission and management information systems over the immediate- and medium-term horizon. The guidance in this document provides a common conceptual framework and vocabulary that AVS organizations can use to coordinate the acquisition, development, and support of information systems.

This SDLC calls for a series of comprehensive management controls. These include:

Life Cycle Management should be used to ensure a structured approach to information systems development and operation.

Each system project must have an accountable sponsor. A single project manager must be appointed for each system project. A comprehensive project management plan is required for each system project. Data Management must be emphasized throughout the life cycle. A system project may not proceed until resource availability is assured.

0.9. DOCUMENTATIONThis life cycle methodology specifies which documentation should be generated during each phase. The outputs of SDLC documentation activities are typically categorized into two major types: process and product, as follows:



QPM #

AQS 200-001-WI

Revision

1


Process Documentation - Process documentation communicates status and direction. It addresses the actions required for developing, implementing, and maintaining the system. Examples include project plans, time lines, funds required, procedures to be followed, and project review reports.

Product Documentation - Product documentation describes the system itself, what it is, how it is operated, and how it is to be maintained. Examples include user manuals, operations manuals, maintenance manuals, requirements documents, and design documents.

Some documentation remains unchanged throughout the systems life cycle while other documents evolve continuously during the life cycle. Some documents are revised to reflect the results of analyses performed in later phases. Each of the documents produced is collected and stored in a project file. Care should be taken, however, when processes are automated. Specifically, components are encouraged to incorporate a long-term retention and access policy for electronic processes. Be aware of legal concerns that implicate effectiveness of or impose restrictions on electronic data or records.



QPM #

AQS 200-001-WI

Revision

1


1 STRATEGIC PLANNING FOR INFORMATION SYSTEMS

1.1. STRATEGIC PLANNINGStrategic planning provides a framework for analyzing where AVS is and where AVS should be in the future. The agency strategic plans required by the Government Performance and Results Act of 1993 (GPRA) provide the framework for implementing all other parts of this Act, and are the key part of the effort to improve performance of government programs and operations. The AVS Strategic Plan guides the annual budget and performance planning. It sets the framework for measuring progress and ensuring accountability to the public. The AVS Strategic Plan is mission driven and includes a vision statement that describes the work environment to accomplish the mission. The strategic plan identifies goals, objectives and strategies in support of the mission and vision. Strategic plans are linked to the overall goals and direction AVS has established. Strategic planning is not part of the SDLC, but determines what information systems projects get started and/or continue to receive funding.

1.2. IRM PLANNING FOR INFORMATION SYSTEMSAVS places major emphasis on planning for the future, investing in information technology, and managing our information resources effectively. Beyond modernizing existing systems, Information Resources Management (IRM) staff is striving to make new and better information, technology, products, and services available to the work force and the public.

IRM planning should be tightly linked to the AVS long-range strategic business plan via measurable objectives of the programs and the systems. As such, IRM plans should be used as agendas before executive boards to make strategic decisions. The information systems plans should have a set of measurable objectives as a means for measuring their achievement of specific business requirements. Consequently, new initiatives and existing systems should contain performance objectives written in business terms. These objectives may be revised over time, as the concept of a new system is refined. They should be based on the expected benefits indicated in the system's cost-benefit analysis.

1.3. PERFORMANCE MEASUREMENTPerformance measurement is an essential element in developing effective systems through a strategic management process. The mission, goals, and objectives of AVS are identified in its strategic plan. Strategies are developed to identify how AVS can achieve the goals. For each goal, AVS establishes a set of performance measures. These measures enable AVS to assess how effective each of its projects is in improving Departmental operations.

For AVS to make this assessment, the current performance level for each measure (performance level baseline) for the existing systems must be determined. For each project plan, as part of the cost benefit analysis, estimate the performance levels expected to be attained as a result of the planned improvements. As the project's improvements are implemented, actual results are compared with the estimated gains to determine the success of the effort. Further analysis of the results may suggest additional improvement opportunities.

The Administration and Congress are seeking improved methods for increasing efficiency in Government. Limited budget resources put an increased emphasis on performance



QPM #

AQS 200-001-WI

Revision

1


measurement systems. A major step toward measuring results was the passage of the Chief Financial Officers Act of 1990, which requires agencies to provide annual audited reports that emphasize financial and program performance measures. OMB Bulletin 97-01 requires agencies to report on significant performance measures that are consistent with major goals from the agency's strategic plan. Other laws calling for performance measures are the 1993 GPRA and the 1996 Clinger-Cohen Act (formerly the Information Technology Management Reform Act).

OMB Circular A-94, Benefit-Cost Analysis of Federal Programs: Guidelines and Discounts, requires a program-based approach for justifying and evaluating information systems. A program approach requires examining an information system, typically a project, in the context of the functional programs it supports, such as enforcement, benefits, and administration. It ties the life cycle cost of the information system to the functional program through the cost benefit analysis (CBA). It ties benefit analysis of the information system and the functional program to measurable high-level business objectives and requirements.

Performance Measurement, along with evaluation are the principal methods for determining if identified benefits are realized in the expected time frame.

1.4. BUSINESS PROCESS REENGINEERINGBusiness Process Reengineering (BPR) involves a change in the way an organization conducts its business. BPR is the redesign of the organization, culture, and business processes using technology as an enabler to achieve quantum improvements in cost, time, service, and quality. Information technology is not the driver of BPR. Rather, it is the organization's desire to improve its processes and how the use of technology can enable some of the improvements. BPR may not necessarily involve the use of technology. There are circumstances when all BPR will entail is an elimination of steps or the process. For BPR to attain large benefits, the use of information technology can be justified.

BPR will increase the demand for horizontal rather than stovepipe systems. BPR will cause the organization to shift because fewer resources may be needed to conduct business. New ways of doing business may also generate new areas of activity that would require additional resources or a more efficient business process may be implemented that may require the same amount of resources. New technologies will improve and simplify many management processes that would deliver improved services to internal and external customers.

The primary underpinning of any new system development or initiative should be BPR. Division or branches should consider BPR before requesting funding for a new project or system development effort. When BPR is applied to one or more related business processes, an organization can improve its products and services and reduce resource requirements. The results of a successful BPR program are increased productivity and quality improvements. BPR is not just about continuous, incremental and evolutionary productivity-enhancements. It also utilizes an approach that suggests scrapping a dysfunctional process and starting from scratch to obtain larger benefits.

Since BPR has been the focus, the technology infusion has caused organizations to flatten or at least reshape their managerial structure. This is largely due to the fact that dissemination of information has improved and increased through the use of networks, locally and worldwide. In essence, information is passed horizontally instead of top-down. The links among external



QPM #

AQS 200-001-WI

Revision

1


organizations and customers, electronically, also makes it increasingly important that standard data formats and standards are compatible. Information systems of the future will increasingly use knowledge bases in conjunction with conventional databases. And finally, most of the performance measurements that are required by business components in an organization ensure that business goals are met, the business is streamlined, performance effectiveness is improved, and that BPR truly delivers the benefits that technology can put in place.

1.5. QUALITY IMPROVEMENT PROCESS AND THE LIFE CYCLEQuality management principles should be integrated into each level of AVS' planning processes. Effective planning is critical to AVS' ability to develop quality information systems. The need for quality planning to deliver improved quality systems and services to our customers more cost-effectively is critical. The declining budget makes it imperative that AVS revamp the way systems are designed and improve quality in services delivered.

This methodology uses an approach that integrates people, processes, and products to support continuous improvement of systems, and organization processes to support organizational goals and objectives better. By promoting user involvement, the SDLC methodology fosters process understanding and provides a medium for continually improving the way individuals in the organization conduct business. By using the tools in this SDLC, users and functional specialists can review current processes and identify enhancements to operations. By facilitating this process improvement, the SDLC methodology encourages application development projects to improve upon current procedures rather than simply to automate them.

This methodology will ensure that each information system project is successful and that offices avoid learning (and relearning) the pitfalls and lessons of information system development the hard way. By committing to continuous quality improvement during the systems life cycle, this approach will ensure full consideration of AVS' program environment, and associated system/data requirements, from project approval through the entire life of the system and produce quality systems.

The IRM organization in AVS has an inherent ownership interest in and responsibility for the information and the information technology it uses to carry out programs. Component organizations exercise this responsibility by developing plans, budgets, and procurement strategies to acquire IT, managing the development and operation of systems, and delivering other IT products and services.

The AVS Strategic IRM Plan describes the major information technology initiatives that have been undertaken to support the AVS mission over the next five years. It describes information resources management strategies, major systems and initiatives that AVS expects to continue or initiate in support of its mission.

Offices are responsible for developing long-range plans for development or acquisition of major information systems. These plans are integral to the analysis for planning the strategic information architecture for AVS.

1.6. BUDGET FORMULATION FOR SYSTEMS INITIATIVESAVS is required by OMB to prepare an annual IT budget. OMB Circular A-11 (Section 53) defines the format for reporting data on Information Technology. This format is designed to provide the basic information needed by agencies to link their internal planning, budgeting, and



QPM #

AQS 200-001-WI

Revision

1


management of IT resources. These exhibits are due in early September each year, for inclusion in the President's Budget.

Circular A-11, Part 3, Planning, Budgeting, and Acquisition of Capital Assets, also requires the submission of Exhibit 300B. This Capital Asset Plan and Justification integrates more fully the OMB investment decision criteria for information technology acquisitions (known as "Raines Rules") to include mapping to the agency's IT architecture, information security requirements, and technical infrastructure. It also clarifies project and contract cost, schedule and performance baselines and emphasizes the acquisition strategy. This requirement is further supported by the Federal Acquisition Streamlining Act of 1994 (FASA) (Title V), which states that OMB report on the cost, schedule, and performance goals for asset acquisitions and how well agencies are meeting the goals. OMB published the Capital Programming Guide in June 1997, to assist agencies in preparing their capital plans and developing their budget requests from their capital plans. These exhibits are also submitted in early September to the budget staff, for inclusion in the president's budget.



QPM #

AQS 200-001-WI

Revision

1


2 KEY SUPPORTING PROCESSES

2.1. OBJECTIVE This section serves as an introduction to several key process areas that should be used throughout the system life cycle to manage the development and operations of information systems. Processes should address:

Understanding customer needs and expectations; Deriving and allocating requirements; Planning the technical effort; Analyzing candidate solutions; Developing physical architectures; Integrating acquisition disciplines; Managing, monitoring, and controlling the technical effort; Integrating the system; Verifying and validating the system; Ensuring quality; Managing configurations; Aligning to the Enterprise Architecture with regards to AS-IS and TO-BE

corporate (AVS) objectives; Managing business risk as well as information security risk; Managing the transition to operational use; Managing system support; Defining and improving management and engineering processes.

For this section, processes are grouped in the general categories of project planning, requirements management, project tracking and oversight, contractor management, verification and validation, quality assurance, change management, and risk management.

All activities and documentation described in this chapter should be tailored to account for the project's complexity and the agency's acquisition management "culture." Complex, new projects should typically use more formal supporting processes while small modifications to existing capabilities would typically use a much-simplified set of the processes described in this chapter.

2.2. PROJECT PLANNINGFor each information system project, AVS should designate a responsible organization and assign the organization sufficient resources to execute the project. Additionally, AVS may tentatively identify the operating organization if different from the project organization.

The project organization should perform the initial project planning described below and present the following System Boundary Document (SBD) elements to the appropriate level for approval:

Project Office Charter and Resource Requirements Acquisition Strategy Paper



QPM #

AQS 200-001-WI

Revision

1


Acquisition Project Baseline Project Schedule Project Cost Estimate

Once approved, these documents should provide the basis for internal project management as well as agency oversight. Any reporting requirements should reference project progress against the approved SBD.

These SBD elements should be reviewed and updated, as appropriate, prior to initiating each system development life cycle phase.

2.2.1. Organizational DevelopmentDevelopment of large information systems requires unique management skills and experience as well as underlying knowledge of the technologies involved in the project. The designated project manager for large information system projects should possess, as a minimum, the following knowledge, skills and abilities.

Demonstrated ability to manage development projects, to include accountability

for project cost, schedule, and technical performance; Knowledge of agency development policies and procedures; Demonstrated ability to manage contracted efforts; Demonstrated ability to represent the project at all levels of the government as

well as to the public.

2.2.1.1. Organizational Alignment

The project office may be placed at any location or level of the agency, as appropriate. In all cases, the designated project manager should not be the warranted contracting officer for any associated contracts.

2.2.1.2. Staffing

The project office organization should be staffed with the appropriate number and kinds of acquisition personnel experienced in the domain of the application being acquired. These individuals may be directly assigned to the project office or matrixed from supporting organizations. Depending on the project size and complexity, project office personnel should include individuals trained and experienced in technical management (engineering, computer science, configuration management, quality assurance, logistics, etc.), business management (finance, cost estimating, business management, etc.), and contract management. Support contractors may augment project office staffing provided all applicable public law and Federal regulations are applied to the efforts (e.g., inherent governmental activities, non-personal services, etc.). Additionally, project office personnel should be supplied with all supplies, equipment, tools, and services needed to accomplish the project objectives.

Information technology development projects, like all acquisition development projects, require personnel with management and technical skills that are congruent with the acquisition strategy selected for the project. Selecting an acquisition strategy that requires skills and experience not present in the available staffing introduces major risks.



QPM #

AQS 200-001-WI

Revision

1


2.2.1.3. Personnel Training

All assigned and supporting project office personnel should be provided continuous opportunities for training in their technical, business, and contract management functions. Additionally, the project office should provide assigned personnel with training specific to the project requirements, with emphasis on training in the area of advanced technologies being applied to the project.

2.2.1.4. Communication Channels

Communications channels should be established through the agency organization to the agency IRM Office, as needed, to provide for internal agency tracking of project progress. Organizational placement should allow sufficient visibility of project needs to allow agency resources to be effectively applied to the project.

The management of the project organization and individual reporting channels should be in accordance with published agency directives. Additionally, for large information system projects, the designated project manager should have a formal, unrestricted communications channel to the AVS and agency Chief Information Officers.

2.2.1.5. Project Office Charter

Effective with the identification of the business need (in the System Concept Development Phase) for a project, the agency should designate the developing project organization. For a new large project, this may require the creation of a new organizational element. For smaller projects and modifications to existing systems, the project may be assigned within a current organizational element. In all cases, the identification of a distinct project organization should also include the identification of a designated project manager who carries both the responsibility and accountability for project execution. The project manager is responsible for creating the SBD. This package, when approved by the project manager, the resource provider, and the decision authority, should constitute a contract between the project manager and the decision authority as detailed in the project office charter. All project reporting, tracking, and oversight should reference this package. The SBD should also contain specific requests for the removal (waivers) of constraints within the purview of the decision authority.

2.2.1.6. Organizational Processes Development

To provide a management structure for the project, the project office should adapt, adopt, or create written processes and procedures for recurring project office activities. This guide defines several of the critical processes essential to the successful project execution. These include requirements management, project tracking, contractor management, verification and validation, quality assurance, change management, and risk management. For agencies with mature acquisition organizations, this activity may be confined to following existing general processes or adapting an existing project's processes to the new project.

For agencies with few defined acquisition processes, this effort may require extensive process development. The Software Engineering Institute (SEI) has developed several extensive Capability Maturity Models (CMMs), including Software Acquisition, Systems Engineering, and People that outline essential processes for acquisition projects. Each development project should strive to achieve at least Level II of the Software Acquisition CMM prior to commencing the Requirements Analysis Phase. For projects requiring significant contracted efforts, the



QPM #

AQS 200-001-WI

Revision

1


project office may require contractors to possess institutionalized processes as recognized by industry standards (CMM, Malcolm Baldridge, or ISO 9000 certifications).

Best Practices: Organizational Development

Designate a responsible organization in writing

Designate a qualified, experienced project leader

Assign sufficient resources to the project

Develop a System Boundary Document and use for all tracking and reporting

Establish effective project communication channels

Use project advisors to apply needed skills

Establish effective processes using the Capability Maturity Models as guidance

2.2.2. Acquisition Strategy DevelopmentAcquisition strategy is a combination of business and technical concepts designed to meet the stated business need within any specified constraints. It is the framework for managing all phases of the life cycle and provides the underlying strategy for all program plans and activities.

While the strategy may evolve over time, it should contain elements from across all life cycle phases, including disposal.

2.2.2.1. Selecting the Overall Acquisition Strategy

Each project strategy will be unique in some respect but should normally be modeled after successful strategies used within the culture of the agency or organization tasked with the development. The acquisition strategy for a project should be included in the SBD. Portions of this document will be repeated in the Acquisition Plan, if required by the FAA Acquisition Management System for contracted efforts.

Items to be considered when selecting which strategies to use include:

Organizational culture and experience Available resources Available schedule Agency risk tolerance Project size Project complexity Maturity of business need Urgency of business need Maturity of organizational processes



QPM #

AQS 200-001-WI

Revision

1


The key to all strategy decisions should be a balance of acquisition risk against the verified business need as illustrated in Figure 3-3. Note that significant system modifications and upgrades to current systems can present more strategy problems than completely new developments. Mixing old and new technologies presents challenges across all of the following considerations.

FIGURE 3-3: ACQUISITION STRATEGY DECISION CONCEPT

2.2.2.2. Elements of Acquisition Strategy

The following items should be considered when developing the acquisition strategy:

Statement of need Significant Conditions Impacting the Effort (e.g., resource constraints, required

interfaces, future requirements) Life-Cycle-Cost Goals Design-to-Cost Goals Application of Special Costing Studies (e.g., should-cost) Required System Capability or Performance Schedule Requirements and Constraints Allowable Cost, Schedule, and Performance Trade-Offs Cost, Schedule, and Performance Risks Risk Management Strategy Special Permissions and Waivers Needed Records disposition, Privacy Act, Freedom of Information Act, and other legal

considerationsUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


Contracting Strategy, to include Incentive Strategy and Contract Type Source Selection Strategy Test and Evaluation Strategy Verification and Validation Strategy Operations and Maintenance Strategy Government-furnished Property, Information, and Facilities Strategy Security Implementation Strategy Communications Strategy Technological Refreshment Strategy Contractor versus Government Performance Selection Strategies Quality Assurance Strategy Interoperability Strategy Systems Engineering/Technical Management Strategy Business/Financial Management Strategy Contract Management Strategy Commercial Off-the-Shelf Hardware and Software Selection Strategies Software Design and Code Reuse Strategies

Each agency should determine the level of detail to be addressed in the acquisition strategy description during each phase of the project. The SBD decision authority should determine which strategy elements should be addressed. Approval of the SBD should constitute management approval to execute the strategy. (Approval to enter into contractual arrangements and expend funds typically follows a separate approval process.)

2.2.2.3. Technical Innovation and Insertion Strategies

As projects proceed through the life-cycle phases, advancing technology and new commercially available capabilities present opportunities for project enhancement. Advances in technology and available commercial systems may also eliminate or significantly modify the underlying business need for the project. Project plans and contracts should allow for controlled use of these opportunities to meet the business need in a "better" way (faster, cheaper, etc.). The insertion strategy must account for two potentially conflicting requirements:

The system may require a fixed interface with external systems and users, and The system may require internal and interface changes mandated by changing

technology (e.g., existing or planned hardware and software are no longer supportable).

The reverse may also be true:

The external interfaces change due to technology advances, and The system design needs to remain constant due to cost or schedule constraints.



QPM #

AQS 200-001-WI

Revision

1


2.2.2.4. Initial Cost Estimates

A project cost estimate is an analysis of projected future costs associated with creating and sustaining a system to meet the business need. The estimate may include all projected costs for the system (life-cycle cost estimate) or include only a portion of the expected cost, such as a development cost estimate or contract cost estimate. As a general statement, cost estimates are best left to the experts to create. Only after the initial estimates are completed should the project team address fiscal reality. If needed, the proposed acquisition strategy or the underlying business need may be adjusted to account for budget realities.

Adjusting to fiscal reality sometimes becomes an integrity issue. If the business need demands cannot be met by the anticipated budget, occasionally pressure is brought to bear to lower the estimate without adjusting the business need. This typically dooms a project to failure. In this case the balance shown in Figure 3-3: Acquisition Strategy Decision Concept should be maintained, with all elements being adjusted until a balance is again reached.

2.2.3. Project Schedule DevelopmentSchedule development uses the same general four methods as cost estimating. Also like cost estimating, typically some type of external constraint (need date) is placed on the scheduling development. As with cost estimating, the accuracy and detail of the schedule increases as the project moves through the life cycle phases. All aspects of the project, including user activities, should be integrated into a master schedule. For complex projects, networked scheduling techniques should be used to provide integrated schedule analysis as well as a method for tracking the execution of interdependent events.

2.2.3.1. Schedule Modeling

Some of the elements that should be considered in scheduling information systems projects include:

Initial requirements analysis, project approval, and funding availability Procurement planning, preparation, and approval Source selection and contract award Contracted system development System integration and testing

Care should be taken to integrate all of these elements since published models usually account for only the last two. As with cost estimating, schedule models produce estimates that vary in accuracy based on the phase of the program. Models used include:

Algorithmic models (equivalent to analogy models) Constructive Cost Model II (COCOMO II) (parametric model) Function Point models (parametric model) Software Life Cycle Management (SLIM) model (equivalent to analogy model but

allows parametric calibration based on completed projects)

Best Practices: Acquisition Strategy



QPM #

AQS 200-001-WI

Revision

1


Adapt successful strategies to the new project

Strategy should balance development risk against the business need

Strategy elements should be allocated to specific organizations

Plan for controlled technical innovation and advancement

Use expert cost estimators using recognized models for initial project estimates

Each model has advantages and disadvantages based on the ability to estimate the required model input parameters and the complexity of the project. In selecting the model, consideration should also be given to the preferences and experience of the SBD decision authority.

Best Practices: Project Schedule Development

Use recognized schedule models acceptable to the project approval authority

Schedule must balance business need against development risk

Integrate all project elements into a single master schedule

Use networked schedule tools for complex projects

2.2.3.2. User Needs versus Development Realities

The documented business need for the system normally comes with a projected need date. The requirements analysis activity early in the product life-cycle phases should verify any stated need date for initial system operation. As part of the initial schedule planning and acquisition strategy decisions, the feasibility of achieving the specified need date should be assessed. If the project cannot deliver the capability by the need date with an acceptable acquisition risk and cost, the project should not be attempted until an acceptable balance among cost, schedule, system performance, and acquisition risk is achieved through negotiations with the user, project office, and decision authority. It is seldom advisable to present a schedule that contains more acquisition risk than the agency or the project manager is willing to accept.

2.2.3.3. Schedule Development and Tracking Tools

Several scheduling tools are available to assist in developing and tracking project schedules. Additionally, contractors may have unique internal scheduling packages integrated into their proprietary management systems. It may be desirable to require contractor schedules to be delivered in a software format compatible with the project office's scheduling system. AVS requires the use of its current product environment.



QPM #

AQS 200-001-WI

Revision

1


2.2.4. Project Planning ActivitiesAcquisition projects involve three areas of management: technical, business, and contracts. Coordinating these three areas is project management and subordinate to the three areas are any number of specialty management areas. Each management area needs to be planned, often resulting in a plan covering a specific area for a specific project phase. Individual project plans should be tailored or combined depending on the project complexity or specific direction from the project decision authority. Additionally, some contracts related plans are required by regulation or public law. Recommended documents and their project phase are shown in Figure 3-4.

FIGURE 3-4: PLANNING DOCUMENTS

Planning Document Sys

tem

Con

cept

D

evel

opm

ent

Pla

nnin

g

Req

uire

men

ts

Ana

lysi

s

Des

ign

Dev

elop

men

t

Inte

grat

ion

and

Test

Impl

emen

tatio

n

Ope

ratio

n an

d M

aint

enan

ce

Dis

posi

tion

System Boundary Document C/F * * * * * *Cost Benefit Analysis C R R R R FFeasibility Study C R FRisk Management Plan C R R R R F * *Acquisition Plan C R F *Configuration Management Plan C R R R F * *Quality Assurance Plan C R R R F * *Concept of Operations C R R R R F * *System Security Plan C R R R R F *Project Management Plan C R R R F *Verification and Validation Plan C R R R FSystems Engineering Management Plan C/F * * * * * * *Functional Requirements Document C FTest and Evaluation Master Plan C R R F * *Interface Control Document C R R R R RPrivacy Ad Notice C FRecords Disposition Schedule C F * *Security Risk Assessment C R R F *Contingency Plan C R F * *Conversion Plan C R F *System Design Document C F *Implementation Plan C R FMaintenance Manual C R F * *Operations / System Admin Manual C R F * *Training Plan C R F * *User Manual C R F * *Software Development Document C R F *System Software C R F *



QPM #

AQS 200-001-WI

Revision

1


Planning Document Sys

tem

Con

cept

D

evel

opm

ent

Pla

nnin

g

Req

uire

men

ts

Ana

lysi

s

Des

ign

Dev

elop

men

t

Inte

grat

ion

and

Test

Impl

emen

tatio

n

Ope

ratio

n an

d M

aint

enan

ce

Dis

posi

tion

Test Files / Data C F *Integration Document C R FTest Analysis Report C F *Test Analysis Approval Determination C/F *Test Problem Reports C CSecurity Certification and Accreditation C/F * *Delivered System Documentation C/F *Change Implementation Notice C CVersion Description Document C/F *Post-Implementation Review Report CPeriodic System Review Report CUser Satisfaction Review CDisposition Plan C/FPost-Termination Review Report C/F

Key: C=Create R=Revised F=Finalized * = Update if needed

2.2.4.1. Program/Project Management Planning

Summary level project planning is conducted as part of preparing or updating the SBD. In addition, detailed project planning is required in the areas of:

Project Office Structure Roles, Responsibilities, and Staffing Management Approach Development Strategy Management and Business Practices Requirements Management User and External Relationships Internal Relationships Project Work Breakdown Structure Project Scheduling Activities Project Budget Planning and Allocation Activities Project-Level Metrics and Baseline Tracking Activities Risk Management, Control, and Mitigation Activities



QPM #

AQS 200-001-WI

Revision

1


The results of management planning may be captured in a formal Program Management Plan. For smaller projects, management planning results may be contained as a sub-element of a single Management Plan that covers project, technical, business, and contract management. See Figure 3-5 for examples of project management planning needs.

FIGURE 3-5: PROJECT MANAGEMENT PLANNING

2.2.4.2. Technical Management Planning

The successful technical management of a project requires establishing and implementing structured, disciplined, and documented system engineering processes, multi disciplinary teamwork, and the simultaneous development of the products and processes to satisfy the business need. The system engineering process is applied iteratively during each project phase to transform the stated need into the system products, processes, and people elements that will meet that need. A sample of the technical planning needs is shown in Figure 3-6.



QPM #

AQS 200-001-WI

Revision

1


FIGURE 3-6: TECHNICAL MANAGEMENT PLANNING HIERARCHY

The results of this planning process are typically captured in a Systems Engineering Management Plan (SEMP). The project office should develop the SEMP prior to starting any significant project activities. For contracted efforts, the government SEMP may be provided as part of the solicitation package with a corresponding contractor SEMP delivered prior to source



QPM #

AQS 200-001-WI

Revision

1


selection. As the project matures technically, individual portions of the system engineering planning may be captured in detailed plans (e.g., Configuration Management Plan, Data Management Plan, Quality Assurance Plan, Transition Plan, Operations and Maintenance Plan).

2.2.4.3. Business/Financial Management Planning

Business management planning involves all financial aspects of the project. These include formulating budget requests, tracking those requests through the funding process, adjusting the project to the realities of the funding made available, defending the available funding from external attack, and adjusting the internal budgets based on project realities.

Business management planning also involves the establishment and tracking of an integrated project schedule. For complex projects, this typically involves establishing an integrated network of events, with dependencies, of the entire project work breakdown structure. Depending on the preference of the project manager, business planning also includes management-reporting planning, to include management metrics selection and measurement as well as contractor earned value analysis and reporting. A sample of business management planning needs is shown in Figure 3-7.

FIGURE 3-7: BUSINESS MANAGEMENT PLANNING



QPM #

AQS 200-001-WI

Revision

1


2.2.4.4. Contract Management Planning

Early in the planning phase, contract planning involves the preparation for major contract events such as solicitation and source selection. This includes preparing the source selection plan and model contract, as well as coordinating the preparation of the technical portion of the solicitation, to include the statement of work and technical specifications.

Contract management planning also includes determining how the contracts will be managed following award, to include use of contracting officer technical representatives, subcontract management planning, change management planning, and fee determination procedures. In some cases, contract management planning also should include contractor audit and certification processes. An example of contract management planning needs is shown in Figure 3-8.

FIGURE 3-8: CONTRACT MANAGEMENT PLANNING

2.3. REQUIREMENTS MANAGEMENTA system requirement is a description of an essential capability or constraint that pertains to the product performance, functional characteristics, and/or physical characteristics. Management of these requirements is essential to successful satisfaction of the user's need.

Requirements management begins with the identification and documentation of the user need. This need should be expressed in user defined terms detailing both their real needs and their expectations. The essence of system requirements analysis is the translation of these needs



QPM #

AQS 200-001-WI

Revision

1


and expectations (through a defined, repeatable, and reversible process) into unambiguous, measurable, technical requirements (e.g., specifications).

Additionally, non-technical requirements should also be developed and managed. These requirements include such things as contractual terms and conditions, license and royalty arrangements, and financial reporting requirements. For all but the very smallest projects, a formal requirements identification, analysis, tracking, and adjudication process should be used.

2.3.1. Identifying the Requirements OwnerAs part of the project planning process, it is essential to identify the user or user surrogate with the authority and responsibility to state the user needs and expectations. This individual or organization should be able to state explicit needs, or at least describe the desired outcome if the need is met. In cases where the identified requirements owner is unable to articulate specific needs, the project office may assist in performing the equivalent of a market or technology analysis to define the possible and feasible outcomes of applying technology to the problem stated by the user. However, the responsible user should then specifically state the need in user--not specification--terms. The need should be captured in a formal statement of need that includes the initial concept of how the system will be used or operated. This initial concept of operations should evolve into detailed operational processes and procedures as the system is implemented.

Best Practices: Project Planning Activities

Develop and use project and system work breakdown structures

Develop and use a system engineering management plan

2.3.2. Identifying the RequirementsUsing the systems engineering management process, requirements are identified through a repeated, recursive process over the acquisition phases of a project. First, the user need is defined and evolved into a top-level requirements hierarchy (requirements architecture). As development proceeds, these requirements are assigned to functional groupings (functional architecture), which are later allocated to system components (physical architecture). For software intensive information systems, these architectures are typically contained in the system specification, the software development specifications, and the code listings/version description documents. Data development/synchronization requirements should also be specifically addressed (data architecture).

2.3.2.1. Identifying the Need

A statement of need should be prepared by the user and summarized in the SBD. Additionally, non-technical needs or unusual externally imposed constraints should also be listed in the initial SBD. In each case, the stated needs should have an owner (originator), and, if possible, a hierarchy of priority in relationship to each other. It should be stated if the needs are inflexible.

For poorly defined or unknown needs on potentially large information systems, the initial acquisition strategy associated with the system development life cycle model should be



QPM #

AQS 200-001-WI

Revision

1


modified to include iterative or experimental needs assessments (to include extensive sub-system prototyping) prior to moving into a more formal acquisition program. Initiating formal projects with unstable user needs typically results in significant cost and schedule problems for the project.

2.3.2.2. Defining System Requirements

The user need is first translated into high-level technical needs that are not system specific. During the initial project phases, these technical needs are analyzed and evolved into system-level requirements. Even at this early stage of development, a formal, robust requirements traceability process is essential to allow tracing system requirements back to the stated user needs. At each phase of development, all system requirements should trace to a need and all needs should trace to system requirements.

2.3.2.3. Implied Requirements

Some requirements will not be driven by the user or business need, but must nonetheless be incorporated into the project at the earliest possible stage. These include requirements that are driven by legislative mandate or agency policy. For example, AVS information security requirements have been derived from federal, DOT, FAA, and AVS policy and must be included in each project’s requirements documentation.

2.3.2.4. Requirements Development by System Element

System functions are allocated to one or more system element: Products (software, hardware, facilities, data, materials, communications), Processes (services, techniques), and People (personnel). At each phase of development, requirements are decomposed into more detailed functions and further allocated to system sub-elements. They should also be written as testable statements. For example, in the end, a very specific, detailed requirement is allocated to a single software module. Essential attributes of a requirement are shown in Figure 3-9.

FIGURE 3-9: REQUIREMENT ATTRIBUTES

Complete Formal Simple

Consistent Minimal Traceable

Correct Modifiable Unambiguous

Feasible Maintainable Verifiable

2.3.3. Controlling the RequirementsThe beginning and most essential step in controlling the requirements of an information technology project is to determine what they are. Having a definitive set of technical and non-technical requirements is critical in controlling project cost and schedule. "Requirements creep" is a common, and sometimes fatal, problem for a project. The only cure is a clear understanding of user needs and expectations. According to SE-CMM best practices, this is accomplished by:

"Eliciting customer needs, expectations, and measures of effectiveness.UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


Analyzing customer needs and expectations to develop a preliminary operational concept of the system as appropriate.

Developing a statement of system requirements. Obtaining concurrence from the customer that the agreed upon customer

requirements satisfy their needs and expectations. Informing the customer on a regular basis about the status and disposition of

needs, expectations, and measures of effectiveness."

See the complete SE-CMM Handbook for details in accomplishing these practices.

Best Practices: Identifying the Requirements

Use the systems engineering process

Ensure all technical requirements trace to a user need and all user needs trace to technical requirements

2.3.3.1. Requirements Baseline Management

Everyone associated with the project manages requirements. However, only a selected set of requirements needs to be baselined and then formally tracked and controlled. These controlled requirements are developed incrementally over the acquisition phases and are captured in formal documentation and tool sets. These baseline documents may include:

User Statement of Need Acquisition Program Baseline Functional Baseline (e.g., system specification) Allocated Baseline (e.g., software development specifications) Product Baseline (e.g., source code listings)

Depending on the complexity of the project, requirements baselines may be tracked using software tools specifically designed for that purpose. These tools allow tracing individual requirements from the stated user need, through the system and subsystem specifications, down to the individual software unit or module.

Additionally, changes to key documentation that describe the basic processes used on the project should be controlled (e.g., SEMP), but not necessarily through a formal process.

2.3.4. Changing the RequirementsNeeds change; opportunities are discovered; errors are found; technical efforts fail; schedules slip; cost estimates are inaccurate; budgets are cut; priorities are adjusted - many things cause requirements to change. As a result, the project team should continuously assess the impact of changes on the project cost, implementation schedule, and system performance. The key to performing these assessments is to be able to trace any requirements change back to highest requirement (user need) and forward to the lowest requirement (software module). This allows accurate identification of changes to development activities, schedules, and costs.



QPM #

AQS 200-001-WI

Revision

1


2.3.4.1. Reactive System Change Management

Requirements changes are a normal part of the development process. Since the project team must react to these issues and still keep the project within the parameters set in the Acquisition Program Baseline, most projects should establish technical, schedule, and budget management reserves. In the technical area, this is sometimes called design margin - that margin above the minimum acceptable need that is justified by design uncertainty. Similarly, schedules are designed with slack and budgets have reserve (or at least have lower priority items which can be eliminated, if needed). The key to successful reactive change management is actually successful cost, schedule, and performance reserve management.

2.3.4.2. Proactive System Change Management

During project development, opportunities may arise that lead to system changes. For example, a new commercial off-the-shelf product may eliminate the need for a development task or advanced state-of-the-art hardware can be applied to the project to either increase performance or reduce life-cycle costs. Proactively, the project office should perform cost-benefit analyses to assess these opportunities. However, incorporating these changes should not unacceptably increase the risk of meeting the stated user need.

Best Practices: Controlling the Requirements

Gain a clear understanding of user needs through a requirements conference

Establish and manage cost, schedule, and performance management reserves

2.4. PROJECT TRACKING AND OVERSIGHTAll projects generate information. This information is used to support decisions impacting the project. An essential task of the project office is to create and manage the information needed to execute the project. For example, information is used to track progress, adjust internal management and technical efforts, inform external oversight activities, justify budget requests, and provide information to decision makers.

As part of the project information management function, the project office should ensure the project tracking and oversight activities get the right information at the right time.

2.4.1. Acquisition Project Baseline DevelopmentThe Acquisition Project Baseline (APB) is the one key set of project information that provides the benchmark against which the project's progress is measured. It should contain only the most important cost, schedule, benefit, and performance parameters. The most important parameters are those that, if not met, would require reevaluation by the decision authority of the desirability of continuing the project.2.4.1.1. Performance Baseline

At project initiation, the baseline performance parameters should be expressed in relatively broad user terms of needed capability or capacity. As the project proceeds through the development phases, additional measures of effectiveness or performance should be added to



QPM #

AQS 200-001-WI

Revision

1


characterize the major project drivers impacting cost, schedule, or performance. Care should be taken to ensure only a minimum, measurable, and internally consistent set of parameters is shown in the APB. This section does not necessarily contain specification values but may show project goals for the parameters. Actual or anticipated failure to meet a baselined threshold parameter requires formal notification to the SBD decision authority.2.4.1.2. Cost Baseline

The cost baseline shows the budgetary requirements for the project to develop, implement, and operate the resulting system according to the schedule, with the benefits shown, and providing the baselined performance. If applicable, the project's actual funding may be shown. Shortfalls between the budget requirements and the available funding must be addressed. Any shortfall in the current funding year or out-year funding requirement that is not expected to be resolved shows the project to be unexecutable. (The APB should be disapproved and the project terminated or restructured within the available funding.) Actual or anticipated exceeding of the baselined budget in any year by 10 percent or anticipated exceeding the total development budget by 10 percent should require formal notification to the SBD decision authority.

2.4.1.3. Schedule Baseline

The baselined schedule parameters should include program initiation; major life-cycle phase transition points, to include initial operational capability (defined to be that point where the end user receives useful system products); final operational capability (defined to be the date the system operations and maintenance organization has total engineering responsibility); and other measurable events proposed by the project manager and approved by the decision authority. Actual or anticipated slips of baselined schedule events that exceed six months require formal notification to the SBD decision authority.

2.4.1.4. Benefits Baseline

If the project requires specific benefits to be shown as a result of the GPRA, these should be shown in the APB. Actual or anticipated failure to meet a baselined threshold benefits parameter requires formal notification to the SBD decision authority.

2.4.2. Oversight ActivitiesInternal and external project oversight activities involve assessing government and contractor progress in meeting the user need described in the APB. These activities include assessing documentation, observing events, and attending non-technical and technical project reviews.

2.4.2.1. Assessing Documentation

Contractor deliverables document the results of the development activities performed to satisfy the user need. Documentation review provides a critical venue to assess and adjust the contractor technical processes and products. To be effective, the assessment of deliverables must be thorough, comprehensive, consistent, and timely. Additionally, external oversight authorities may require periodic reports from the project office detailing progress or providing information on specified items of interest.

2.4.2.2. Observing Events

As part of normal government oversight activities, government personnel (e.g., quality assurance) observe selected project activities, ranging from contractor-conducted test events to



QPM #

AQS 200-001-WI

Revision

1


government-conducted configuration control board meetings. Additionally, external observers may participate in project office as well as contractor activities as directed by the decision authority or by established agency policy.

2.4.2.3. Project Reviews

These non-technical management reviews are held on a recurring basis to provide a forum to assess the project's cost, schedule, and technical performance progress. The objectives of the review include ensuring scheduled activities are completed, identifying problem areas, and determining the most appropriate course of action. These reviews provide the opportunity for face-to-face communications and promotion of common understanding and expectations by the project stakeholders.2.4.2.4. Design Reviews

The purpose of a major design review is to provide information in support of a decision to allow the project to proceed into the next stage of development. Specifically, the review provides assessments of:

Completion of the design activities scheduled, the maturity of the processes supporting those activities, and the readiness of the design to move into the next stage of development

Completion of the planning for continuing technical efforts and the maturity of the processes that will support those efforts

The risks and mitigation strategies associated with continuing project development and implementation

Design reviews should be event-based, not schedule driven. As such, a detailed set of design review entrance criteria should be developed to define the criteria that must be met prior to holding the review. Similarly, design review exit criteria should be used to define the events that must be completed before the review is formally concluded. Entrance and exit criteria should be realistic and achievable. However, once developed, they should be enforced. This ensures the overall integrity of the technical effort.

The phasing and content of design reviews should be detailed in the SEMP. As a general statement, at least one major design review should be held towards the conclusion of each development life cycle phase to assess the readiness to move to the next phase. While guidance documents call these reviews by different names, their purpose remains as stated above - providing information in support of a decision.

2.4.2.5. Audits

The project office, as well as its contractor, is subject to external audit. This includes government oversight audits (Government Accounting Office, Inspector General, etc.) and commercial certification audits (e.g., ISO 9000 compliance certification). Additionally, the project office may conduct or assist in conducting formal audits associated with project configuration management activities or contractor earned value accreditation/certification.

For example, FAA policy requires that every information system undergo an information security assessment prior to beginning production processing. This assessment must be completed in part by an independent third party. So the project office must ensure that its schedule allows



QPM #

AQS 200-001-WI

Revision

1


time for this assessment to be completed, and must coordinate with the AVS Information Systems Security Manager (ISSM) to ensure that it is completed. Additionally, current legislation, like the Clinger-Cohen Act and GPRA, require use of Enterprise Architecture to guide the decision-making and planning processes associated with program acquisition. GAO is auditing alignment with EA on a more consistent basis.

2.4.2.6. Project Metrics

Measuring project status and system attributes is an essential function of oversight. However, each measurement action diverts effort from meeting the stated user need. Therefore, measurement should be limited to the minimum essential to accomplish the project objectives.

In selecting measurements (commonly referred to as metrics), they should not only status the project at present but also be predictive of future key project parameters. For example, a metric of current estimated source lines of code is predictive of future project cost and test schedule achievability. Metrics should be focused in the following areas.

Schedule and progress Resources and cost Growth and stability Product quality Development performance Technical adequacy

An effective metrics program is characterized by:

Project issues and objectives that drive the measurement requirements The developer's process that defines how the software is actually measured Collecting and analyzing low level data Implementing an independent analysis of capability Using a structured analysis process to trace the measures to the project

decisions Interpreting the measurement results in the context of other project information Integrating software measurement into the project management process

throughout the life cycle Using the measurement process as a basis for objective communications

Best Practices: Oversight Activities

Establish and enforce entrance and exit criteria for major design reviews

Establish a Technical Performance Measurement program for a limited number of technical parameters



QPM #

AQS 200-001-WI

Revision

1


2.4.3. Program/Project Tracking Tools2.4.3.1. System Requirements

For complex projects, it is recommended that system requirements be formally tracked using a government provided automation tool (e.g. Rational, System Architect). It is also desirable to use the selected tracking tool as an interface to any computer-aided software engineering (CASE) tools used on the project to ensure a consistent and traceable set of requirements is applied to the project. For contracted projects, the government and contractor requirements tracking tools should allow complete interchange of information.

2.4.3.2. Schedule Tracking

Schedule tracking should typically use the same tool used to create the schedule. If needed, networking tool sets used to track detailed project tasks (e.g., program evaluation review technique (PERT)) should be capable of creating input files to scheduling systems whose use is dictated by the project decision or oversight authority (e.g., The Component mandates Microsoft Project for all schedules).

2.4.3.3. Financial Tracking

For significant contracted efforts, numerous financial tracking needs exist. These include tracking budgets and outlays for:

Program Office (Government) direct personnel costs (if separately tracked) Program Office indirect personnel costs (training, supplies, etc.) Program Office infrastructure costs (facilities, utilities, office equipment, networks,

etc.) Program Office travel costs Program Office support contractor costs User interface costs (travel, major design reviews, information services, etc.) External government support costs Contract budget commitments Contract obligations Contract expenditures Management reserves

This tracking can typically be done using a spreadsheet (e.g., Microsoft Excel). For large projects or projects with volatile cost drivers, financial tracking tools should be integrated with predictive tools/models to provide continuous projections of budget needs. A goal should be to integrate the technical, schedule, and financial tools to allow the project manager to assess the impact of project issues and changes. For significant contracted efforts, an integrated tool is Earned Value Analysis. (See section 2.5.2.1)



QPM #

AQS 200-001-WI

Revision

1


2.5. CONTRACTOR MANAGEMENT2.5.1. Prime Contractor Management2.5.1.1. Roles of the CO and COTR

The Contracting Officer (CO) in an effort has the authority (warrant) to obligate the government to pay for services and products. The CO is the only individual authorized to change a contract - including changing the technical requirements. To aid the CO in these duties, the CO may appoint, in writing, a Contracting Officer’s Technical Representative (COTR) with specific delegated authority to clarify and interpret the contract. COTRs should be extensively trained on all expected duties and responsibilities prior to being assigned as a COTR. They also need to be certified. For typical information systems projects, the project manager should be assigned COTR responsibilities for the development efforts.

2.5.1.2. Roles of Project Office and Oversight Staff

Project office staff advises the COTR on all project activities and may participate in technical interchanges with the contractor. However, only the COTR may clarify a contractual requirement and only the CO may change a contractual requirement. Oversight personnel, regardless of position or perceived authority, may not clarify nor change contractual requirements.2.5.1.3. Subcontract Management

Except as explicitly specified in the contract, the government may not interfere in the management of a subcontractor nor in any way usurp the authority of the prime contractor in controlling a subcontractor. However, this does not preclude government comments to the prime contractor on its assessment of the subcontractor's performance.

2.5.2. Contract Performance TrackingContractor progress is tracked through all available means, including delivered documents, test results, design reviews, technical performance measures, and audit results. A key tool in providing an integrated assessment of contractor performance is earned value analysis.

2.5.2.1. Earned Value Analysis

Earned value analysis provides government and contract project managers’ visibility into technical, cost, and schedule progress against an established plan to provide the product or services required by a contract. An earned value management system provides information that:

Relates time-phased budgets to specific contract tasks Indicates work progress against the planned efforts Properly relates cost, schedule, and technical accomplishment

To be effective, the contractor must plan the work effort in sufficient detail to provide budget as a function of time and expected technical progress as a function of labor resources (work packages). Progress against these budgets and work packages are then measured and reported. Earned Value is a tool that may be used by the government as a predictor of future risk, and analysis of past trends and performance. Government experience has shown that properly executed earned value efforts accurately predict performance and cost.



QPM #

AQS 200-001-WI

Revision

1


2.5.2.2. Incentive and Award Fee Determinations

Contracts using incentive fees reward the contractor with profit based on finite, measurable performance, such as cost. For example, for a cost-plus-incentive-fee contract, the contractor is awarded different profit percentages based on the final contract cost, with the lower the final cost, the higher the profit. For award fee contracts, the government bases the award fee (profit) on a subjective analysis of the contractor's performance of items contained in a negotiated award fee plan.

2.5.3. Project Support Contract ManagementIn some cases, support contractors may augment the project office staff. Support contracts are normally associated with "services." A services contract refers to efforts that are designed to perform a task as compared to produce an end item. Refer to the FAA Acquisition Management System , for details on services contracting. Normally, services’ contracting is restricted to non-personal services that do not involve inherent government activities.

2.5.3.1. Inherent Government Activities

Services contractor personnel are precluded from performing activity reserved for the government. These activities include: representing the government, supervising government personnel, and making decisions for the government.

2.5.3.2. Non-Personal Services

Non-personal services refers to those contracts under which the personnel supplying the services are not subject to contract terms and conditions or by the manner of contract administration to government supervision or control usually prevailing between the government and its employees. A vast majority of support contracts are non-personal in nature. This means that any appearance of an employer-employee relationship between government and contractor personnel is prohibited.

2.5.3.3. Task Order Management

Most services contracts contain a description of tasks to be performed. A "task order" is essentially a statement of work to be performed together with a list of the deliverables (typically reports). However, the emphasis is placed on the service provided that creates the report, not the report itself. Government technical management of this type of effort requires both technical and contracting oversight and review. Additionally, project office personnel (COTR) should be involved in the administrative aspects of contract monitoring (e.g., certifying hours expended, acceptance of deliverables).

2.5.4. Technical Contract Management2.5.4.1. Informal Technical Contract Management

Day-to-day technical management and oversight of contracted efforts is accomplished through informal communications channels, exchanges of technical information, and technical interchange meetings (TIMs). The project office should establish explicit guidance that these informal exchanges of information do not result in technical direction outside the scope of the contract. In-scope clarifications of the contract should only be made by the COTR under delegation from the CO.



QPM #

AQS 200-001-WI

Revision

1


2.5.4.2. Formal Technical Contract Management

Formal oversight of contracted technical activities is accomplished through review, comment, and approval of technical documentation. Additionally, formal oversight is conducted through activities associated with formal design reviews. Again, all formal actions are documented by the COTR and CO.

2.5.5. Financial Contract ManagementFor all types of contracts, the project office should actively monitor the financial status of the contract as well as the overall financial health of the contractor. For contracts with cost incentives, the project office should track contract costs (actual and projected) against the planned expenditures. For cost-plus contract types, additional emphasis should be placed on tracking current costs and cost estimates-to-complete to ensure adequate financial reserves are maintained to complete the project.

2.5.6. Contract Change ManagementControlling change on contracted efforts requires continuous tracking of changes that may impact the cost, schedule, or performance specified by the contract. These types of changes are documented and presented for consideration and incorporation to the contract. For some efforts, the government may task the contractor to study a problem and prepare a study report.

2.6. VALIDATION, VERIFICATION, AND TESTING2.6.1. Validation ProcessThe validation process is a process for determining whether the requirements and the final, as-built system or software product fulfills its specific intended use. While some validation efforts involve studies and analysis, a majority of validation efforts focus on testing a product or process to provide assurance that it fulfills all of its requirements. Modeling and simulation may also be used.

2.6.1.1. Independent Validation Need Determination

A determination shall be made if the project warrants a validation effort and the degree of organizational independence of that effort needed. For systems that require assurance that all user requirements are met in the implemented system, validation should be performed independent of the individual responsible for the product or process. This independence may range from a test office within the developing organization to an independent organization or contractor validation activity. Independent validation is always appropriate for critical information systems and subsystems whose failure may put human life at risk. Independent validation is required by FAA policy for certain information security activities.

2.6.1.2. Validation Activities

The organization performing the validation effort needs to prepare the selected test requirements, test cases, and test specifications for analyzing test results. Ensure that these test requirements, test cases, and test specifications reflect the particular requirements for the specific intended use. Conduct the tests to include stress, boundary and singular inputs. Test the software product for its ability to isolate and minimize the effect of errors; that is, graceful degradation upon failure, and request for operator assistance upon stress, boundary, and



QPM #

AQS 200-001-WI

Revision

1


singular conditions. Also, test that representative users can use the software successfully to achieve their intended results.

2.6.2. Verification ProcessThe verification process is a process for determining whether the software products of an activity fulfill the requirements or conditions imposed on them in the previous activities. For cost and performance effectiveness, verification should be integrated, as early as possible, with the process that employs it. This activity may be accomplished by analysis, review, and/or test. For information system development projects, verification may include analysis of contract documents, requirements lists, design specifications or software code to determine if all user needs and requirements have been addressed. Verification is performed throughout the system development life cycle.

2.6.2.1. Independent Verification Need Determination

A determination shall be made if the project warrants a verification effort and the degree of organizational independence of that effort needed. For systems that require assurance that requirements are met, verification should be performed independent of the individual responsible for the product or process. This independence may range from a peer review within the organization to an independent organization or contractor verification activity. The project requirements shall be analyzed for criticality. Verification may be needed if the potential of an undetected error in a system or software requirement exists for causing death or personal injury, mission failure, or financial or catastrophic equipment loss or damage. The maturity of and risks associated with the software technology to be used and availability of funds and resources are other reasons for verification.

2.6.2.2. Verification Activities

Based on the scope, magnitude, complexity, and criticality, target life cycle activities and software products requiring verification shall be selected. A verification plan must be developed and documented. The plan shall address the life cycle activities and software products subject to verification, the required verification tasks for each life cycle activity and software product, and related resources, responsibilities, and schedule. There are several areas where verification should be used.

Contract Verification: The contract shall be verified to assure that the supplier has the capability to satisfy the requirements, and that the requirements are consistent and cover user needs. Ensure that adequate procedures for handling changes to the requirements and escalating problems are stipulated. Procedures and their extent for interface and cooperation among the parties need to be stipulated, including ownership, warranty, copyright and confidentiality. Acceptance criteria and procedures also need to be stipulated in accordance with requirements.

Process Verification: Verify that the project planning requirements are adequate and timely. Ensure that the processes selected for the project are adequate, implemented, being executed as planned, and compliant with the contract. Verify that the standards, procedures, and environments for the project's processes are adequate. The project also needs to be staffed and personnel trained as required by the contract.



QPM #

AQS 200-001-WI

Revision

1


Requirements Verification: Verify that the system requirements are consistent, feasible and testable. The system requirements need to be appropriately allocated to hardware items, software items, and manual operations according to design criteria. Software requirements also need to be consistent, feasible, testable, and accurately reflected in the system requirements.

Design Verification: The design is verified to be correct and consistent with and traceable to requirements. The design implements proper sequence of events, inputs, outputs, interfaces, logic flow, allocation of timing and sizing budgets, and error definition, isolation, and recovery. Ensure that the selected design can be derived from the requirements.

Code Verification: The code should be traceable to design and requirements, testable, correct, and compliant with requirements and coding standards. The code should implement proper event sequence, consistent interfaces, correct data and control flow, completeness, appropriate allocation timing and sizing budgets, and error definition, isolation, and recovery. The selected code should be derived from design or requirements.

Integration Verification: The software components and units of each software item should have been completely and correctly integrated into the software item. The hardware items, software items, and manual operations of the system should be completely and correctly integrated into the system. The integration activities should be performed and verified against the integration plan.

Documentation Verification: The documentation should be adequate, complete, and consistent. It should be prepared in a timely fashion. Configuration management of the documents should follow specified procedures.

Information Security Verification: Information security requirements must be met, and formal documentation must be prepared to describe how they are met. This documentation, called a Security Certification and Accreditation Package (SCAP) must comply with the FAA SCAP Handbook published by the Office of Information Security (AIS).

Enterprise Architecture Verification: Ensure that relevant information about the application and its relationship to business processes and data elements are properly documented in the AVS Enterprise Architecture.

2.6.3. Test and EvaluationTest and evaluation is a subset of verification and validation that requires specific actions by the project office. Contracted test efforts and demonstrations provide a primary means of assessing the technical progress and remaining risk during the development and deployment of a new or modified information system. The project office should ensure that the system test program is sufficiently detailed to determine that:

The system meets its specifications The system is satisfactorily integrated into its environment The system can be sustained in service The system provides a useful function or service



QPM #

AQS 200-001-WI

Revision

1


The system presents an acceptable risk if placed in operations. This encompasses both business risk as well as information security risk.

2.7. QUALITY ASSURANCEThe Quality Assurance process is a process for providing adequate assurance that the software products and processes in the project life cycle conform to their specified requirements and adhere to their established plans. To be unbiased, quality assurance needs to have organizational freedom and authority from persons directly responsible for developing the software product or executing the process in the project. A quality product or service, by definition, meets or exceeds the need to which the product or service is applied. This process consists of four activities listed below.

2.7.1. Process ImplementationThe quality assurance process should be responsible for conducting on-going evaluations of software acquisition, supply, development, maintenance, operation, and supporting process activities and the resulting software products to assure that each process, activity, and task required or described in plans is being performed in accordance with those plans. It should also assure that each software product required by a relevant process exists and has undergone software product evaluations, testing, and problem resolution, as required. A plan for conducting the quality assurance process activities and tasks shall be developed, documented, implemented, and maintained for the life of the contract. An outline for the Quality Assurance Plan can be found in Section 19, Quality Assurance Plan.

2.7.2. Product AssuranceAssure that all the plans required are documented, comply with requirements, are mutually consistent, and are being executed as required. All software products and related documentation should adhere to the plans. Software products that have fully satisfied contractual requirements may be assumed to be acceptable to the acquirer. The quality assurance process should be performed to assure that all products exist, have undergone evaluations in accordance with the plans for conducting quality assurance activities and tasks, and satisfy the acceptance criteria. Product assurance personnel or teams may use the results of verification, validation, and other processes to satisfy product assurance tasks.

2.7.3. Process AssuranceAssure that those software life cycle processes (supply, development, operation, maintenance, and supporting processes, including quality assurance) employed for the project adhere to the plans. Internal software engineering practices, development environment, test environment and libraries must comply with the requirements. The acquirer needs the required support and cooperation to carry out these processes. This means that the staff assigned to the project has the skill and knowledge needed to meet the requirements and receive any necessary training.

2.7.4. Assurance of Quality SystemsA quality product or service, by definition, meets or exceeds the need to which the product or service is applied. With this as a framework, a few significant characteristics of a quality product or service are:

Meets the user's needUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


Meets the user's requirements Meets the user's expectations Allows the user to accomplish a task to which the product or service applies Is available to the user when the task to which the produce or services applies is

accomplished For a continuing product or service, uniformly and consistently meeting the user's

need, requirement, and/or expectation allows the user to "trust" the continued use of the product or service

Meets the user's affordability or other constraints

In summary, a quality product or service meets expectations and is useful, available, consistent, and affordable when applied to a task.

2.7.5. Organizational AlignmentTo effectively accomplish the above activities, an entity to carry out the project quality assurance function (QA) should be assigned to the project. Those responsible for the process or product are responsible for resolving problems found by the QA entity. The organization performing the quality assurance is responsible for assuring the problem is verified and resolved. For small projects managed within existing organizations, quality assurance expertise may be provided by external (e.g., matrixed) organizations if the supplied expertise is independent of the project's technical, business, and contracting management activities.

2.8. CONFIGURATION MANAGEMENTAll project and contractor personnel who are developing, acquiring, disposing, operating, or maintaining project systems should use documented change management methodology to ensure that system requirements are clearly defined and controlled throughout the life of the system and that the operational system satisfies the needs of the project. To accomplish these tasks, the following should be accomplished:

A project Configuration Management Plan should be developed. Configuration baselines should be established, documented and controlled using

a formal change control processes. Fielded systems should be documented and software releases and system

upgrades documented and controlled using a formal process.

2.8.1. Technical Baseline ManagementThe initial step of Baseline Management is the identification of what is to be managed. The purpose of configuration identification is to establish and maintain a definitive basis for control and status accounting of systems throughout all life cycle phases. Configuration identification includes selecting configuration items (CIs), assigning unique CI identifiers, documenting the CIs, and establishing and managing configuration baselines. A CI is a system component (hardware or software) or logical group of components that satisfy an end-use function. CIs are uniquely identified and placed under configuration control. At a minimum, the following shall be selected as CIs:

The system itself, defined as the top-level CI.



QPM #

AQS 200-001-WI

Revision

1


All COTS software and hardware needed for the system (or application) to function or required for re-procurement.

Application software components already designated as CIs. Project support software essential for system maintenance, including debuggers,

test scripts, and configuration checkers. Information security controls implemented in the system.

2.8.1.1. Baseline Documentation

Configuration baseline documents include both project documents and any other user-support documents subject to change when the project changes. Baseline documents should be maintained throughout the life of the project, including the Operations and Maintenance Phase and Disposition Phase. Baseline documentation including application software components and COTS products are required to be identified as a CI and brought under baseline control. This applies even if the project may not control the updating of the item (e.g., COTS software). A version number should uniquely identify different versions of applications software. Because COTS items (hardware or software) are not developed in-house, they are not subject to the same level of configuration control as other CIs. However, if a COTS product is modified or configured by the project, it is then subject to the same configuration control procedures as any other CI.

2.8.1.2. Configuration Baseline Management

Once a baseline (made up of baselined documentation) has been established, it should not be changed without a formal action. The typical baselines used for information systems are the functional baseline (FBL), allocated baseline (ABL), and product baseline (PBL). Baselines are normally established successively with each one adding more detail about the final system. Each project configuration management (CM) plan should list the complete contents of each baseline.

2.8.1.3. Functional Baseline

The FBL is the approved documentation that describes the system (or product) functional characteristics. After approval of the Functional Requirements Document during the Requirements Analysis phase, the FBL is established. This baseline should be maintained throughout the life cycle of the project.

2.8.1.4. Allocated Baseline

The ABL is the approved documentation that describes the design of the functional and interface characteristics that are allocated from a higher level CI. All fielded systems shall have an ABL to support test, training, and maintenance. This baseline shall be maintained throughout the life cycle of the project, usually by the organization responsible for maintaining the functional products described in the baseline documents.

2.8.1.5. Product Baseline

The PBL consists of completed and accepted system components and the corresponding documentation that identifies these products. This baseline supports the ability to accurately duplicate software, purchase COTS, and modify COTS. The PBL includes source code on electronic media, COTS (hardware and software), maintenance and user manuals, vendor-



QPM #

AQS 200-001-WI

Revision

1


supplied COTS manuals, purchase specifications for modified COTS, system and hardware drawings, Version Description Documents, and code listings. This baseline should be maintained throughout the Operations and Maintenance, and Disposition Phases.

2.8.2. Configuration ControlConfiguration control is the systematic proposal, justification, evaluation, coordination, approval (or disapproval), and implementation of changes after formal establishment of a configuration baseline. Configuration control is initiated after the FBL is established and extends to include the ABL and PBL, once established. Changes should be approved by the proper authority (as defined in the project CM Plan).

2.8.2.1. Implementation of Changes

After changes have been approved, they are designed, developed, tested, and implemented. The processes for implementing software and hardware changes should be described in the project CM Plan. Supporting documentation, to include user-support documentation should be delivered as part of any change implementation.

2.8.3. Configuration Status AccountingThe purpose of Configuration Status Accounting (CSA) is to record, store, maintain, correlate, and report the status of an evolving CI throughout the system life cycle. CSA requires that all software and related documentation be carefully tracked from initial development, through the approval or disapproval of changes, to the implementation of changes. CSA records and monitors all changes to baselines. As a result of this effort, CSA will maintain traceability of the hierarchy of requirements from the stated user need at the top, through the functional and allocated baseline documentation, and down to the lowest level of the product baseline.

2.8.4. Configuration AuditsA Configuration Audit is a formal review of a project for the purpose of assessing compliance with the CM plan. The purpose of a Functional Configuration Audit (FCA) is to ensure that the functional requirements have been met by the delivered CI. FCAs shall be performed for application software, COTS products, and customized products that satisfy a functional requirement. The FCA is the responsibility of the system tester and the project configuration manager. The purpose of a Physical Configuration Audit (PCA) is to ensure that all physical attributes listed in the design requirements have been met by the CI to be delivered.

2.9. RISK MANAGEMENTRisk Management (RM) is the process of assessing risk, taking steps to reduce risk to an acceptable level and maintaining that level of risk. It also refers to the process of accepting, transferring, or mitigating risk. Risk Management activities include documenting and identifying project risks; analysis, assessment, and prioritization of those project risks; and laying out plans to implement actions to reduce the project risks throughout the project's life cycle. Risk Management planning provides a control mechanism to monitor, report, and direct all risk mitigation activities. Risk management is initiated during the System Concept Development Phase and continues through all subsequent phases. Refer to the NIST Handbook, Special Publication 800-12, for guidance on risk management for information systems.



QPM #

AQS 200-001-WI

Revision

1


It is important to distinguish between project risk and information security risk, since the terminology related to both is often the same. Project risk refers to the probability that planned activities will not have the expected outcome. This type of risk must be managed in conjunction with schedules and other project plans and documentation. Information security risk refers to the probability that a vulnerability could be exploited, and must be managed in conjunction with information security requirements as well as other management and technical documentation.

2.9.1. Project Risk 2.9.1.1. Project Risk Identification

Risk is an undesirable situation or circumstance, which has both a probability of occurring and a potential consequence to project success. Project risk has an impact on cost, schedule, and performance. Project risk identification is the process of identifying uncertainty within all aspects of a project. In other words: what might go wrong and what happens if it does. For most information system projects, these risks may be grouped in the following categories:

Technical. Risk associated with creating a new capability or capacity Supportability. Risk associated with implementing, operating, and maintaining a

new capability Programmatic. Risk caused by events outside the project's control, such as

public law changes Cost and Schedule. Risk that cost or schedule estimates are inaccurate or

planned efficiencies are not realized

Risks should be identified continuously by project participants (at all levels) and the project management team should capture these risks in definitive statements of probability and impact. Lessons-Learned from previous projects may be a significant source for identifying potential risks on a new project.

2.9.1.2. Project Risk Analysis

Risk Analysis quantifies the identified risks and conducts detailed sensitivity studies of the most critical variables involved. The outcome of these analyses may be a quantified list of probabilities of occurrence and consequences that may be combined into a single numerical score. This single score allows project risks to be prioritized.

2.9.1.3. Project Risk Planning

Risk planning decides what to do about a project risk. Available actions are:

Avoid the risk. Control the risk Assume the risk Transfer the risk

The action selected for each risk will depend on the project phase, the options that are available, and the resources that can be used for risk management. A majority of project activities involve tracking and controlling the project risk.



QPM #

AQS 200-001-WI

Revision

1


2.9.1.4. Project Risk Tracking

Risk tracking involves gathering and analyzing project information that measures risk. For example, test reports, design reviews, and configuration audits are risk tracking tools used by project management to assess the technical risk of moving forward into the next life cycle phase.

2.9.1.5. Project Risk Control

Risk control takes the results of risk tracking and decides what to do and then does it. For example, if a project design review shows inadequate progress in one area, the decision may be made to change technical approaches or delay the project.

2.9.1.5.1. Project Risk Mitigation Techniques

Risk mitigation techniques are used to control or transfer risk until an acceptable risk level is reached. The most common techniques are inherent in good management and engineering practice:

Budget management reserve mitigates cost risk Schedule slack mitigates schedule risk Parallel development mitigates technical risk Prototyping mitigates technical risk Incentive fee and incentive-firm contract types mitigates cost risk Entrance and exit criteria for major design reviews mitigates cost, schedule and

technical risks

2.9.1.5.2. Project Risk Communication

Risk information should be communicated to all levels of the project organization and to appropriate external organizations. This ensures understanding of the project risks and the planned strategies to address the risk. Risk information then feeds the decision processes within the project and should establish support within external organizations for mitigation activities. For example, an agency comptroller who understands the project risks is more likely to allow the project manager to have a management reserve within the project budget.

Communicating risk information in a clear, understandable, balanced, and useful manner is difficult. The ability to state the problem at hand clearly, concisely, and without ambiguity is essential. Ensure that the mitigation activities conveyed include alternatives, objectively stated justifications and trade off analyses. A well-planned and executed risk management program ensures the decision maker receives unbiased information - resulting in the best project decisions.

2.9.2. Information Security Risk Information security risk is the analysis of vulnerabilities in a system and the possibility that a vulnerability might be exploited to cause harm. Information security risk management focuses on the impact of such an exploit to the system’s confidentiality, integrity, or availability (or to the data managed by the system) if a vulnerability is exploited.



QPM #

AQS 200-001-WI

Revision

1


Information security risk can be mitigated by the implementation of security controls. Since vulnerabilities can arise in the management environment, the operational environment, or in the technical aspects of the system, security controls can also be implemented in each of these aspects of the system.

There are two key activities that must be completed during the system’s development to ensure that information security risk is appropriately managed. The first is to incorporate the information security requirements (see Section 50, Information Security Requirements) into the system at the earliest possible stage. The second is to complete the Security Certification and Accreditation Package before the system begins production processing.

Once the system has completed its development and has begun production processing, it must be monitored and updated through the remainder of lifecycle so that its security is adequately maintained and enhanced as needed.



QPM #

AQS 200-001-WI

Revision

1


3 PHASE 1: SYSTEM CONCEPT DEVELOPMENT PHASE

3.1. OBJECTIVESSystem Concept Development begins when a need is formally identified as requiring study and analysis that may lead to system development activities. To get to this point, it must be recognized that such a need exists and then articulate that need to a decision-maker (See Figure 4-10).

FIGURE 4-10: SYSTEM CONCEPT DEVELOPMENT PHASE INITIATION

System needs may arise from external sources, such as public law, the general public or state/local agencies, other Federal agencies that have a customer/supplier relationship with the developing AVS office, and available commercial products marketing. System needs may also arise from internal agency sources requiring new services, sustainment of current services, or improved current services based on newly available technology. While each case is different, a common aspect of need generation is the existence of an advocate who commits the need to paper and pushes the articulated need to the initial decision-maker. To ensure the highest probability of successfully "selling" the need, the advocate should enlist the counsel of all stakeholders in defining the initial need statement. Upon acceptance ("approval") of the need statement by the initial decision-maker, the decision-maker then sponsors the need through the appropriate project initiation process.

For needs entirely within the purview and resources of the sponsor, the sponsor may forward the need to an existing, subordinate development organization for action and formal project initiation. For activities that may require uncommitted agency resources, the sponsor may choose to forward the need to the agency CIO office for prioritization and funding prior to project initiation. Finally, for potentially major development projects or needs falling under the



QPM #

AQS 200-001-WI

Revision

1


responsibility of other AVS offices, the sponsor may advocate agency approval of forwarding the need to AVS for action.

Following review and approval, some form of agency approval (tasking directive) should be issued to begin the formal studies and analysis of the need. The issuing of the tasking directive initiates the System Concept Phase and begins the life cycle of an identifiable project.

3.2. TASKS AND ACTIVITIESThe following activities are performed as part of the System Concept Development Phase. The results of these activities are captured in the four phase documents and their underlying institutional processes and procedures (See Figure 4-11).

FIGURE 4-11: SYSTEM CONCEPT DEVELOPMENT PHASE ACTIVITIES

3.2.1. Refine and State the System NeedThe paper written by the organization's advocate is further refined and studied. The purposes of this activity are to remove solution specific language and state the need in such as way to allow multiple alternatives to be studied. Additionally, this activity should include formal involvement of all stakeholders to ensure the complete need is stated in end-user terms.

3.2.2. Form a Project OrganizationThis activity involves the appointment of a project manager and core supporting elements to execute the program. For small efforts, this may only involve assigning a project to a manager within an existing organization that already has an inherent support structure. For new, major projects, a completely new organizational element may be formed - requiring the hiring and reassignment of many technical and business specialists. However, regardless of project size, the AVS Information Systems Security Manager (ISSM) should be consulted during this initial phase regarding information security activity and requirements.



QPM #

AQS 200-001-WI

Revision

1


Early in this phase, the AVS Enterprise Architect should be consulted to assess the possibility of leveraging existing applications to satisfy the business need.

Additionally, as the organization evolves, internal processes should be developed or adapted to guide the project team through all subsequent life-cycle phases. Organizational and project resource requirements should be studied, justified, requested, and brought to bear on the project in an effective, time-phased manner.

3.2.3. Form the Project Acquisition StrategyThe project team should determine the strategies to be used during the remainder of the project concurrently with the development of the CBA and Feasibility Study. See Section 2.2.2 for the multiple strategy elements that should be considered during this activity.

3.2.4. Plan the ProjectThe project team should plan the subsequent acquisition phases to allow development of project schedule and budget requirements. Additionally, if applicable, the expected performance benefits should also be estimated as part of this life-cycle phase.

3.2.5. Study and Analyze the Stated NeedThe project team, supplemented by enterprise architecture experts, if needed, should analyze all feasible technical, business process, and commercial alternatives, either existing or to-be-developed, to meeting the stated need. The Enterprise Architecture shall be used to “map” the project to the business, technical, data, and service EA Reference Models. This identifies other AVS investments and applications that support the same business processes in order to assess opportunities for application leverage, reuse, integration, or consolidation. These alternatives should then be analyzed from a life-cycle cost perspective. The results of these studies should show a range of feasible alternatives based on life-cycle cost, technical capability, and scheduled availability. Typically, these studies should narrow the system technical approaches to only a few potential, desirable solutions that should proceed into the subsequent life-cycle phases.

Information security requirements must also be considered here, since they may have management, operational, or technical impact to the project. As the studies begin to narrow the range of possible solutions, specific requirements can be earmarked for inclusion in requirements documentation.

3.2.6. Study and Analyze the Acquisition RiskConcurrent with and following the development of feasible alternatives, the risks associated with further development should be studied. The results of these risk assessments should influence the acquisition strategy choices discussed previously.

3.2.7. Obtain ResourcesEstimate, justify, submit requests for, and obtain resources to execute the project.

3.2.8. Document the Phase EffortsThe results of the phase efforts are documented in the System Boundary Document, Cost Benefit Analysis, Feasibility Analysis, and Risk Management Plan.



QPM #

AQS 200-001-WI

Revision

1


3.2.9. Review and Approval to ProceedThe results of the phase efforts are presented to project stakeholders and decision makers together with a recommendation to

Proceed into the next life-cycle phase, Continue additional conceptual phase activities, or Terminate the project.

The emphasis of the review should be on

The successful accomplishment of the phase objectives, The plans for the next life-cycle phase, and The acquisition risks associated with moving into the next life-cycle phase.

The review also addresses the availability of resources to execute the subsequent life-cycle phases. The results of the review should be captured in a tasking directive reflecting the decision on the recommended action.

3.3. ROLES AND RESPONSIBILITIESEach AVS office should develop internal processes to gather information about information processing needs within their mission area. While the sources of these needs may be internal or external to the agency, an internal agency office (e.g., IRM office) should be charged with gathering these needs and providing the essential advocacy role. The advocate (or "Need Champion") is responsible for drafting the initial "white paper" articulating the need and pushing the resulting paper into the appropriate decision maker.

Sponsor: If the decision maker accepts the need for action, the decision maker becomes the sponsor and should provide direction and sufficient study resources to commence the System Concept Development Phase. This tasking directive should include the appointment of a project manager.

Project Manager: The appointed project manager is charged with leading the efforts to accomplish the System Concept Development Phase tasks discussed above.

System Proponent: AVS should designate an individual or group to assist the project manager as the end system user representative. This function provides continuing project advocacy and clarification/expansion of the need. The system proponent should review project office efforts to derive high-level system requirements from the formally stated functional need.

Information Systems Security Manager: The ISSM is responsible for serving as an advocate for information security requirements, and for oversight of security deliverables.

AVS Enterprise Architect. The individual or team that is responsible for management of the AVS Enterprise Architecture program. The enterprise architect is responsible for providing corporate awareness of existing programs and assisting in the assessment of impact for changes or additions to the portfolio of programs managed by AVS for its customers.

3.4. DELIVERABLES, RESPONSIBILITIES, AND ACTIONSThe following deliverables shall be initiated during the System Concept Development Phase:



QPM #

AQS 200-001-WI

Revision

1


3.4.1. System Boundary DocumentThe System Boundary Document identifies the scope or capability of a system. It should contain general business requirements (including information security requirements), benefits, business assumptions, and program costs and schedules.

3.4.2. Cost-Benefit AnalysisProvides cost or benefit information for analyzing and evaluating alternative solutions to a problem and for making decisions about initiating, as well as continuing, the development of information processing-related services.

3.4.3. Feasibility StudyProvides an overview of a business requirement or opportunity and determines if feasible solutions exist before full life-cycle resources are committed.

3.4.4. Project Risk Management PlanIdentifies project risks and specifies the plans to reduce or mitigate the risks.

3.5. ISSUES FOR CONSIDERATIONAfter the feasibility study and CBA are conducted, and a recommendation is accepted by the program and/or executive management, the system project begins. The executive management staff of the organization makes a number of project continuation and project approach decisions.

3.5.1. Project Continuation DecisionsThe feasibility study and CBA confirm that the defined information management concept is significant enough to warrant an information systems project with life-cycle management activities.

The feasibility study should confirm that the information management need or opportunity is beyond the capabilities of existing systems and that developing a new system is a promising approach.

The CBA confirms that the projected benefits of the proposed approach justify the projected resources required. The funding, personnel, and other resources shall be made available to proceed with the Planning Phase.

3.5.2. Project Approach DecisionsEach project shall have an individual designated to lead the effort. The individual selected will have appropriate skills, experience, credibility, and availability to lead the project. Clearly defined authority and responsibility must be provided to the Project Manager.

The Project Manager will work with the System Proponent to identify the scope of the proposed program, participation of the key organizations, and potential individuals who can participate in the formal reviews of the project. This decision addresses both programmatic and information management-oriented participation as well as technical interests in the project that may be known at this time.



QPM #

AQS 200-001-WI

Revision

1


In view of the nature and scope of the proposed program, the key individuals and oversight committee members who will become the approval authorities for the project will be identified.

The Project Manager and System Proponent will determine if any particularly unusual programmatic, technical, or information management skills or experience will be needed. Organizations not participating directly in the project may be notified if appropriate. Whenever the concept is shared among multiple organizations, data administration should play a strong role.

The System Proponent organization will be responsible for providing funding for personnel, contractor support, and other resources needed to undertake the project.

The System Proponent identifies planning and budget information for a new activity or updates information for any existing activities that will be the focus of this proposed program. Management approval to commit resources to the proposed program marks the beginning of the subsequent system development life-cycle phases.

3.5.3. ADP Position Sensitivity AnalysisAutomated Data Processing (ADP) position sensitivity designation analysis applies to all personnel, including contract support personnel, who are nominated to fill an ADP position. ADP positions are those that require access to AVS ADP systems or require work on management, design, development, operation, or maintenance of AVS automated information systems. The sensitivity analysis should be conducted only to determine an individual's eligibility or continued eligibility for access to AVS ADP systems or to unclassified sensitive information (all AVS information is considered unclassified sensitive). Such an analysis is not to be construed as the sole determination of eligibility.

Therefore, all projects must ensure that personnel who will support the project are cleared to the appropriate level before performing work on sensitive systems, and that the positions to be occupied by these individuals are given a sensitivity designation. FAA Order 1600.1d, Personnel Security Program, provides guidance on how to perform the position sensitivity designation, and on the process for clearing federal government employees. For contractor personnel, FAA Order 1600.72 describes the requirements for initiating a background check, obtaining badges if the contractor will require access to FAA facilities, and ensuring that contractor personnel comply with security requirements.

The Project Manager must ensure that all project support personnel have read security documentation, understand how to apply this to the project’s requirements, or can provide evidence of having read the appropriate documentation. AVS personnel are required to sign AVS Rules of System Use annually, and the Project Manager may choose to have contractors sign this document as well.

3.5.4. Identification of Sensitive SystemsPublic Law 100-235, the Computer Security Act of 1987, requires Federal agencies to identify systems that contain sensitive information. In general, a sensitive system is a computer system that processes, stores, or transmits sensitive-but-unclassified (SBU) data. SBU data are any information that the loss, misuse, or unauthorized access to, or modification of, could adversely affect the national interest, the conduct of AVS programs, or the privacy to which individuals are entitled under the Privacy Act.



QPM #

AQS 200-001-WI

Revision

1


All AVS data is considered Sensitive But Unclassified, and therefore, so are the systems that process this data. Additional analysis of data and system sensitivity will be conducted in subsequent SDLC phases.

3.5.5. Enterprise Architecture in System Concept DevelopmentLegislation (Clinger-Cohen Act, GPRA, etc) mandates the implementation and use of Enterprise Architecture to guide decision-making for organizational investments in Information Technology. OMB, in Circulars A-130 and A-11, provides further guidance on how EA should be managed and implemented. GAO audits federal entities to ensure compliance with the legislated requirements for implementation and use of EA. Their reports impact the Federal Budget.

OMB’s guidance (Circular A-130) requires that “agencies identify, define, and organize the activities that capture, manipulate, and manage the business information to support the business processes. The EA also describes the logical dependencies and relationships among business activities.” A-130 defines specific requirements to identify and document data descriptions and relationships as well as the technical architecture of an agency.

Funding for AVS national applications is provided through FAA and AVS funding streams. OMB requires that investments demonstrate conformance to business, data, application, and technology layers of the Federal Enterprise Architecture. OMB Circular A-11 Exhibit 300 provides the reporting templates used to justify investments through the FAA Acquisition Management System up to the congressional level. The Enterprise Architecture is used to provide AVS Integrated Program Managers with information required for Exhibit 300s.

The agency Enterprise Architecture must document linkages between mission needs, information content, and information technology capabilities. It is to be used to guide strategic and operational planning.

3.6. REVIEW ACTIVITYThe System Concept Development Review shall be performed at the end of this phase. The review ensures that the goals and objectives of the system are identified and that the feasibility of the system is established. Products of the System Concept Development Phase are reviewed including the budget, system design, risk, and user requirements. This review is organized, planned, and led by the Program Manager and/or representative.



QPM #

AQS 200-001-WI

Revision

1


4 PHASE 2: PLANNING PHASE

4.1. OBJECTIVEMany of the plans essential to the success of the entire project are created in this phase; the created plans are then reviewed and updated throughout the remaining phases. The plans created within this phase include:

The QA Plan which is reviewed and amplified upon as necessary within the Requirements Analysis Phase, it is then finalized in the Design Phase

The Project Management Plan created in this phase is reviewed and changed as necessary in Requirements Analysis, Design and Development Phases and will then be finalized in the Integration and Test Phase.

The Systems Engineering Management Plan (SEMP) will be both created and finalized in this Phase.

The Concept of Operations (CONOPS) will be created in the Planning Phase, and reviewed and changed as necessary in the Requirements Analysis, Design, Development, Integration and Test Phases and will be finalized in the Implementation phase.

The CM Plan created in this Phase will be reviewed and changed if necessary in the Requirements Analysis, Design, and the Development Phases and will be finalized in the Integration and Test Phase.

The Acquisition Plan will be created in the Planning Phase, reviewed in the Requirements Analysis Phase and finalized in the Design Phase.

The System Security Plan created in this Phase will be reviewed in a number of the phases including the Requirements Analysis, Design, Development, and in Integration and Testing Phase. It will be finalized in the Implementation Phase.

The preliminary Risk Assessment created in this Phase will also be reviewed, updated, and finalized in subsequent phases.

The Validation and Verification Testing Plan when required, will be created in the Planning Phase and reviewed and updated as required in the Requirements Analysis, Design, and Development Phases and will be finalized in the Integration and Test Phase.

In addition to creating the above plans, there is also the responsibility to review certain plans developed during the System Concept Development Phase. Those plans that are reviewed are the CBA, the Feasibility Study and the Risk Management Plan.

4.2. TASKS AND ACTIVITIESThe following tasks are performed as part of the Planning Phase. The results of these activities are captured in various project plans and solicitation documents.

4.2.1. Refine Acquisition Strategy in SBDDuring this phase, the decision should be made on the role of system development contractors during the subsequent phases. For example, one strategy option would include active



QPM #

AQS 200-001-WI

Revision

1


participation of system contractors in the Requirements Analysis Phase. In this case, the Planning Phase must include complete planning, solicitation preparation, and source selection of the participating contractors (awarding the actual contract may be the first activity of the next phase).

4.2.2. Analyze Project ScheduleAnalyze and refine the project schedule, taking into account acquisition risk and resource availability. Develop a detailed schedule for the Requirements Analysis Phase.

4.2.3. Create Internal ProcessesCreate, gather, adapt, and/or adopt the internal management, engineering, business management, information security, and contract management internal processes that will be used by the project office for all subsequent life-cycle phases. Refer to the SEI Software Acquisition Capability Maturity Model for examples of needed processes. Plan, articulate, and gain approval for the resulting processes (QA Plan, CM Plan, V&V Plan).

4.2.4. Staff Project OfficeFurther staff the project office with needed skills across the broad range of technical and business disciplines. If needed, solicit and award support contracts to provide needed non-personal services that are not available through agency resources.

4.2.5. Establish Agreements with StakeholdersEstablish relationships and agreements with internal and external organizations that will be involved with the project. These organizations may include agency and oversight offices, agency personnel offices, agency finance offices, internal and external audit organizations, and agency resource providers (people, space, office equipment, communications, etc).

4.2.6. Plan the Project Management PlanPlan, articulate and gain approval of the strategy to execute the management aspects of the project (Project Management Plan). Develop a detailed project work breakdown structure.

4.2.7. Plan the Systems Engineering Management PlanPlan, articulate, and gain approval of the strategy to execute the technical management aspects of the project (SEMP). Develop a detailed system work breakdown structure.

4.2.8. Review Feasibility of System AlternativesReview and validate the feasibility of the system alternatives developed during the previous phase (CBA, Feasibility Study). Confirm the continued validity of the need (SBD).

4.2.9. Study and Analyze Security ImplicationsStudy and analyze the security implications of the technical alternatives and ensure the alternatives address all aspects or constraints imposed by security requirements



QPM #

AQS 200-001-WI

Revision

1


4.2.10. Draft Preliminary Security PlanThe Information System Security Plan (ISSP) will, when finalized, document all security aspects of the system and will describe how the security of the system and its information will be managed through their lifecycle.

The first step in drafting the ISSP is for the Project Manager to carry out the security categorization activity required by Federal Information Processing Standard (FIPS) 199, “Standards for Security Categorization of Federal Information and Information Systems”. This activity is the basis for many of the other security activities that will take place during the remainder of the System Development Life Cycle. Security categorization may be applied to either the information processed by the system or to the system itself.

To conduct the security categorization activity the system developer must know the type of information that the system will process and how it effects the organization. The information, and consequently the system itself, must be evaluated in terms of the security objectives as defined by FISMA (Confidentiality, Integrity and Availability).

When completed, the security categorization itself and process used to arrive at that conclusion will be documented in the ISSP.

4.2.11. Preliminary Risk AssessmentThe preliminary risk assessment activity consists of an evaluation, based on the system security characterization result, of the system’s security needs. The system developer must consider the system and the information processed, stored or transported by the system and the degree of impact which the loss or compromise of that information or system would have on the organization. This is done informally and at a high level, avoiding specific security solutions. For example, the developer may identify a need for confidentiality for certain files, but may not yet consider the method used to achieve the confidentiality). The result of this activity is an initial description of the high-level security needs of the system in the Risk Assessment document.

Since it is not possible to completely remove all risk, the ultimate goal is to minimize it. Throughout the risk assessment process, beginning in this early phase and continuing as the assessment is updated, the developer should identify those risks that will continue to exist after the system is implemented. These post-implementation risks will be subsequently divided into two categories: those that are acceptable and will be managed as described in the Security Plan, and those that are not acceptable and must be corrected as soon as feasible.

4.2.12. Plan the Solicitation, Selection and AwardDuring this phase or subsequent phases, as required by the FAA Acquisition Management System, plan the solicitation, selection and award of contracted efforts based on the selected strategies in the SBD. Obtain approvals to contract from appropriate authorities (Acquisition Plan). As appropriate, execute the solicitation and selection of support and system contractors for the subsequent phases.



QPM #

AQS 200-001-WI

Revision

1


4.2.13. Develop the CONOPSBased on the system alternatives and with inputs from the end-user community, develop the concepts of how the system will be used, operated, and maintained; document them in the CONOPS.

4.3. ROLES AND RESPONSIBILITIESProject Manager: The project leader is responsible and accountable for the successful execution of the Planning Phase. The project leader is responsible for leading the team that accomplishes the tasks shown above.

Project Team: The project team members (regardless of the organization of permanent assignment) are responsible for accomplishing assigned tasks as directed by the project manager.

Contracting Officer: The contracting officer is responsible and accountable for preparing solicitation documents under the guidance of the program manager.

ISSM: The ISSM is responsible for providing guidance related to preliminary information security planning.

AVS Enterprise Architect. The individual or team that is responsible for management of the AVS Enterprise Architecture program. The enterprise architect is responsible for establishing and maintaining an Enterprise Architecture that complies with legislated requirements and OMB Guidance. Additionally, the architect provides information to guide planning and decision-making for agency Information Technology investments.

Oversight Activities: Agency oversight activities, including the IRM office, provide advice and counsel to the project manager on the conduct and requirements of the planning effort. Additionally, oversight activities provide information, judgments and recommendations to the agency decision makers during project reviews and in support of project decision milestones.

Project Decision Maker: At an appropriate level within the agency, an individual should be designated as the project decision authority (may or may not be the same individual designated as the sponsor in the previous phase). This individual should be charged with assessing: (1) the completeness of the planning phase activities, (2) the robustness of the plans for the next life-cycle phase, (3) the availability of resources to execute the next phase, and (4) the acceptability of the acquisition risk of entering the next phase. For applicable projects, this assessment also includes the readiness to award any major contracting efforts needed to execute the next phase. During the end of phase review process, the decision maker may (1) direct the project to move forward into the next life-cycle phase (including awarding contracts), (2) direct the project to remain in the Planning Phase pending completion of delayed activities or additional risk reduction efforts, or (3) terminate the project.

4.4. DELIVERABLES, RESPONSIBILITIES, AND ACTIONS4.4.1. Project Management PlanThis plan should be prepared for all projects, regardless of size or scope. It documents the project scope, tasks, schedule, allocated resources, and interrelationships with other projects.



QPM #

AQS 200-001-WI

Revision

1


The plan provides details on the functional units involved, required job tasks, cost and schedule performance measurement, milestone and review scheduling. A revision to the Project Management Plan occurs at the end of each phase and as information becomes available. See Section 22, Project Management Plan.

4.4.2. Systems Engineering Management PlanThe SEMP describes the system engineering process to be applied to the project; assigns specific organizational responsibilities for the technical effort, and references technical processes to be applied to the effort. Information that should be included in the SEMP is shown in Section 24, Systems Engineering Management Plan.

4.4.3. Concept of OperationsThe CONOPS is a high-level requirements document that provides a mechanism for users to describe their expectations from the system. Information that should be included in the CONOPS document is shown in Section 20, Concept of Operations.

4.4.4. Configuration Management PlanThe CM Plan describes the process that will be used to identify, manage, control, and audit the project's configuration. The plan should also define the configuration management structure, roles, and responsibilities to be used in executing these processes (See Section 18, Configuration Management Plan).

4.4.5. Acquisition PlanThis document shows how all government human resources, contractor support services, hardware, software and telecommunications capabilities are acquired during the life of the project. The plan is developed to help insure that needed resources can be obtained and are available when needed. An outline is provided in Section 17, Acquisition Plan, detailing the types of information that should be included in the Acquisition Plan.

4.4.6. System Security PlanA formal plan detailing the types of computer security is required for the new system based on the type of information being processed and the degree of sensitivity. Usually, those systems that contain personal information will be more closely safeguarded than most. See NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems, November 1998.

4.4.7. Preliminary Risk AssessmentThe preliminary Risk Assessment will describe the system’s information, and any potential vulnerabilities and threats that might exploit those vulnerabilities. At this early stage, most of the threats and vulnerabilities described will probably be in the management or operational aspects of the system, since its technical features are not yet known.

4.4.8. Validation and Verification PlanThe Validation and Verification Plan describes the testing strategies that will be used throughout the life-cycle phases. This plan should include descriptions of contractor, government, and appropriate independent assessments required by the project (See Section 23, Verification and



QPM #

AQS 200-001-WI

Revision

1


Validation Plan). The Plan for these assessments must include a System Test and Evaluation of the security controls which will be subsequently implemented in the system.

4.5. ISSUES FOR CONSIDERATION4.5.1. Audit TrailsAudit trails, capable of detecting security violations, performance problems and flaws in applications should be specified. Include the ability to track activity from the time of logon, by user ID and location of the equipment, until logoff. Identify any events that are to be maintained regarding the operating system, application and user activity.

4.5.2. Access Based on "Need to Know"Prior to an individual being granted access to the system, the program manager's office should determine each individual's "Need to Know" and should permit access to only those areas necessary to allow the individual to adequately perform her/her job.

4.5.3. Enterprise Architecture in PlanningEnterprise Architecture requirements should be considered when creating the plans associated with this phase of the lifecycle. AVS IT investments must be linked to mission needs and the TO-BE Architecture should reflect the existence of planned investments and their related linkages to mission, data, and the AVS technical architecture.

While not all plans require interfacing with the AVS Enterprise Architect, consultation with the EA should be included for plans based on the scope of the project. At a minimum, the PMP, CM plan, Acquisition plan (to ensure EA documentation of IT investments with funding streams), and Validation and Verification plan should include tasks involving consultation of the AVS Enterprise Architecture. Often the exchange of information is two-way with regard to the EA.

4.6. REVIEW ACTIVITYUpon completion of all Planning Phase tasks and receipt of resources for the next phase, the Project Manager, together with the project team should prepare and present a project status review for the decision maker and project stakeholders. The review should address:

Planning Phase activities status, Planning status for all subsequent life-cycle phases (with significant detail on the

next phase, to include the status of pending contract actions), Resource availability status, and Acquisition risk assessments of subsequent life cycle phases given the planned

acquisition strategy.



QPM #

AQS 200-001-WI

Revision

1


5 PHASE 3: REQUIREMENTS ANALYSIS PHASE

5.1. OBJECTIVEThe Requirements Analysis Phase will be initiated when a project is approved for development in the Initial Planning Review or by management direction. Documentation related to user requirements from the Planning Phase shall be used as the basis for further user needs analysis and the development of detailed user requirements. The analysis may reveal new insights into the overall information systems requirements, and, in such instances, all deliverables should be revised to reflect this analysis.

During the Requirements Analysis Phase, the system shall be defined in more detail with regard to system inputs, processes, outputs, and interfaces (both internal and external). This definition process occurs at the functional level. The system shall be described in terms of the functions to be performed, not in terms of computer programs, files, and data streams. The emphasis in this phase is on determining what functions must be performed rather than how to perform those functions. During the Requirements Analysis Phase, the Project Team will:

Further define and refine functional and data requirements, Complete business process engineering of the functions to be supported, Develop detailed data and process models, Define functional and system requirements that are not easily expressed in data

and process models, such as information security requirements. Refine the high level architecture and logical design to support the system and

functional requirements, and Continue to identify and mitigate risk that the technology can be phased-in and

coordinated with the business.

5.2. TASKS AND ACTIVITIESThe following tasks are performed during the Requirements Analysis Phase. The tasks and activities actually performed depend on the nature of the project. Guidelines for selection and inclusion of tasks for the Requirements Analysis Phase may be found in Section 12, Alternative SDLC Work Patterns.

5.2.1. Analyze and Document Requirements.First consolidate and affirm the business needs. Then document the functional requirements and the data requirements. Connect the functional requirements to the data requirements. Update the data dictionary/repository/encyclopedia. Develop the data model. Validate and verify the data model.

5.2.2. Update Risk AssessmentUpdate the security risk assessment to include:

the identification of threats to and vulnerabilities in the information system; the potential impact or magnitude of harm that a loss of confidentiality, integrity, or

availability would have on an agency’s assets or operations, and



QPM #

AQS 200-001-WI

Revision

1


the identification and analysis of security controls for the information system based on functional requirements.

The selection of appropriate types of safeguards or countermeasures should take into consideration the results of the security assurance requirements analysis. The security risk assessment, in turn, may identify deficiencies in the analysis of integrity, confidentiality, and availability requirements or the security assurance requirements analysis by demonstrating the logical conclusion of the analyses.

5.2.3. Develop Functional Requirements Document (FRD)The FRD is a record of the above requirements. This is a deliverable during the Requirements Analysis Phase. See Section 25, Functional Requirements Document.

5.2.3.1. Incorporate Information Security Requirements

AVS information security requirements have been documented, and are summarized in Section below. After a review of mandated requirements, development teams should adapt these requirements to the system by stating them in specific terms related to the policy, functional, and other IT requirements that have already been identified. Care should be taken to clearly address all of the security objectives, integrity, availability and confidentiality.

This activity should address the developmental activities required to effectively meet AVS requirements, such that the information security integrated into the system will work effectively and efficiently. As with other aspects of security, the goal should be cost-effective assurance that meets the requirements for protection of an organization’s information assets. That is, a balance should exist between the impact to mission performance by system security and the risks associated with operation of the system.

5.2.3.2. Coordinate Alignment of Functional Requirements with Enterprise Architecture

If functional business process reengineering has impacted the CONOPS, or further refinement is made of the functional and data requirements, the AVS Enterprise Architecture should be revisited to check for consistency and analyze further opportunities for leveraging existing IT resources for reuse, integration, or consolidation. The enterprise architecture should reflect the relationships to logical data model entities connected with the application and the To-Be Architecture should remain current with the vision of the CONOPS and FRD.

5.2.4. Develop Test Criteria and PlansEstablish the test criteria and begin test planning. Include all areas where testing will take place and who is responsible for the testing.

5.2.5. Develop the Test and Evaluation Master PlanDescribe what will be tested in terms of the data, security features, or information. If individual modules are being tested separately, this needs to be stated in the Master Plan. Smaller plans may be needed for specialized testing, but they should all be referenced in the Master Plan.



QPM #

AQS 200-001-WI

Revision

1


5.2.6. Develop an Interface Control DocumentThe project team responsible for the development of this system needs to articulate the other systems (if any) this system will interface with. All areas that connect need to be documented for security as well as information flow purposes. Further coordination with the AVS Enterprise Architect is required to fully document information flow and relationships in the To-Be AVS Architecture. The ICD is a deliverable for the Requirements Analysis Phase. (See Section 27, Interface Control Document)

5.2.7. Prepare FOIA/PA DocumentsIf needed, a Privacy Act Notice for the Federal Register will be prepared. Check with the Records Management representative who is responsible for determining if a system is a Privacy Act System of Records. As with the Privacy Act Notice, check with the Records Management representative to see if this is necessary for the system under development.

5.2.8. Conduct ReviewsThe Functional and Data Requirements Review and the Logical Design Review are conducted in the Requirements Analysis Phase by the technical review board, which should include at least one information security representative. This is where the functional requirements identified in the FRD are reviewed to see if the system will be able to support them.

5.2.9. Revise Previous DocumentsThe System Concept Development Phase documents (SBD, CBA, Feasibility Study and the Risk Management Plan) need to be revised and updated if necessary. The Planning Phase documents (Project Management Plan, SEMP, CONOPS, CM Plan, Acquisition Plan, System Security Plan, Risk Assessment, and the V&V Plan) need to be updated in this phase.

5.3. ROLES AND RESPONSIBILITIESProject Manager: The project leader is responsible and accountable for the successful execution of the Requirements Analysis Phase. The project leader is responsible for leading the team that accomplishes the tasks shown above.



ISSM: The ISSM is responsible for reviewing information security deliverables (Security Plan and Risk Assessment) to assess their compliance with FAA standards and guidelines.

AVS Enterprise Architect. The enterprise architect should be consulted to ensure proper documentation of the relationships of applications with other applications, business processes, data, technical architecture, and services to enable the organization to make informed acquisition decisions for Information Technology investments.



QPM #

AQS 200-001-WI

Revision

1


AVS Information Technology Training Program Manager. The IT Training PM is responsible for coordinating the training requirements associated with the deployment and on-going operational education requirements for AVS applications.

Oversight Activities: Agency oversight activities, including the IRM office, provide advice and counsel to the project manager on the conduct and requirements of the Requirements Analysis Phase effort. Additionally, oversight activities provide information, judgments, and recommendations to the agency decision makers during project reviews and in support of project decision milestones.

5.4. DELIVERABLES, RESPONSIBILITIES, AND ACTIONS5.4.1. 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 subject matter experts document these requirements into the requirements traceability matrix, which shows mapping of each detailed functional requirement to its source. This is a complete, user oriented functional and data requirements for the system which must be defined, analyzed, and documented to ensure that user and system requirements have been collected and documented to ensure that:

1. All requirements can be traced to the SBD or users' statement of need document.

2. Business process descriptions contained in the CONOPS are further refined. The detailed design is captured in either the Detailed Design document or the Functional and Data Requirements Definition and must be consistent with the CONOPS.

3. A logical model is constructed that describes the fundamental processes and data needed to support the desired business functionality. This logical model will show how processes interact and how processes create and use data. These processes will be derived from the activity descriptions provided in the System Boundary Document.

4. Functions and entity types contained in the logical model are extended and refined from those provided in the Concept Phase. End-users and business area experts will evaluate all identified processes and data structures to ensure accuracy, logical consistency, and completeness.

5. An analysis of business activities and data structures is performed to produce entity-relationship diagrams, process hierarchy diagrams, process dependency diagrams, and associated documentation.

6. An interaction analysis is performed to define the interaction between the business activities and business data. This analysis produces process logic and action diagrams, definitions of the business algorithms, entity life-cycle diagrams, and entity state change matrices.

7. Training requirements worked in coordination the AVS IT Training PM should be incorporated in the FRD in order to document the future need for the program.

8. A detailed analysis of the current technical architecture, application software, and data is conducted to ensure that limitations or unique AIS requirements have not been overlooked and that information security requirements have been considered.



QPM #

AQS 200-001-WI

Revision

1


These requirements must include considerations for capacity and growth. Where feasible, I-CASE tools should be used to assist in this analysis, definition, and documentation. The requirements document should include but is not limited to records and privacy act, electronic record management, record disposition schedule, and components' unique requirements. Consideration must also be given to persons with disabilities as required by the Rehabilitation Act, 20 U.S.C., Sec 794d (West Supp. 1999).

5.4.2. Test and Evaluation Master PlanEnsures that all aspects of the system, including security, are adequately tested and can be implemented; documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. Unit, integration, and independence acceptance testing activities are performed during the development phase. Unit and integration tests are performed under the direction of the project manager. Independence acceptance testing is performed independently from the developing team and is coordinated with the Quality Assurance (QA) office. Acceptance tests will be performed in a test environment that duplicates the production environment as much as possible. They will ensure that the requirements are defined in a manner that is verifiable. They will support the traceability of the requirements form the source documentation to the design documentation to the test documentation. They will also verify the proper implementation of the functional requirements.

The types of test activities discussed in the subsequent sections are identified more specifically in the Integration and Test Phase of the life cycle and are included in the test plan and test analysis report.

Unit/Module Testing Subsystem Integration Testing Independent Security Testing Functional Qualification Testing User Acceptance Testing Beta Testing

5.4.3. Interface Control DocumentThe Interface Control Document (ICD) provides an outline for use in the specification of requirements imposed on one or more systems, subsystems configuration items or other system components to achieve one or more interfaces among these entities. Overall, an ICD can cover requirements for any number of interfaces between any number of systems; refer to Section 27, Interface Control Document, to see how multiple interfaces among multiple systems can be handled.

5.4.4. Privacy Act RequirementsFor any system that has been determined to be an official System of Records (in terms of the criteria established by the Privacy Act (PA)), a special System of Records Notice shall be published in the Federal Register. This Notice identifies the purpose of the system; describes its routine use and what types of information and data are contained in its records; describes where and how the records are located; and identifies who the System Manager is. While the Records Management Representatives are responsible for determining if a system is a PA



QPM #

AQS 200-001-WI

Revision

1


System of Records, it is the System Owner or System Proponent's responsibility to prepare the actual Notice for publication in the Federal Register. As with the Records Disposition Schedule, however, it is the IRM Manager's responsibility to coordinate with and assist the System Proponent in preparing the PA Notice.

The System of Records Notice shall be a required deliverable for the Requirements Analysis Phase of system development.

5.4.5. Records Disposition ScheduleFederal regulations require that all records no longer needed for the conduct of the regular business of the agency be disposed of, retired, or preserved in a manner consistent with official Records Disposition Schedules. The decisions concerning the disposition criteria, including when and how records are to be disposed, and the coordination with the Records Management representatives to prepare the Records Disposition Schedule for the proposed system, shall be the responsibilities of the System Proponent. It is important, however, for the IRM Manager and System Technical Leads to be involved in this process.

The Project Manager should be aware of any programmatic decisions (including records management-related factors) concerning the system for which IRM has development and operational responsibility.

The Project Manager (and System Technical Leads) may have technical knowledge that could influence the decisions to be made by the System Proponent.

The IRM Manager should therefore assist the System Proponent in coordinating with the Records Management representatives to prepare the Records Disposition Schedule for the proposed system. The Records Disposition Schedule shall be a required deliverable for the Requirements Analysis Phase of system development.

5.5. ISSUES FOR CONSIDERATIONIn the Requirements Analysis Phase, it is important to get everyone involved with the project to discuss and document their requirements. A baseline is important in order to begin the next phase. A developer obtains the requirements from the FRD that may become part of the Request for Proposals (RFP).

5.5.1. Enterprise Architecture in Requirements AnalysisBy this phase, the AVS Enterprise Architecture should reflect the planned existence of the application in the TO-BE architecture (and possibly the AS-IS architecture). Any changes in Concept of Operations that happen during requirements gathering should be reported so the architecture remains up-to-date and impact of the changes can be assessed against existing and planned architectural elements.

Another significant OMB A-130 requirement that should be incorporated into the architecture during this phase is the identification and documentation of Information Flow and Relationships. A-130 guidance says, “Agencies must analyze the information utilized by the agency in its business processes, identifying the information used and the movement of the information. These information flows indicate where the information is needed and how the information is shared to support mission functions. The development of the Interface Control Document (ICD)



QPM #

AQS 200-001-WI

Revision

1


should be coordinated with the AVS Enterprise Architect and the final documentation coordinate to ensure accurate reporting in the architecture.

5.6. REVIEW ACTIVITYUpon completion of all Requirements Analysis Phase tasks and receipt of resources for the next phase, the Project Manager, together with the project team should prepare and present a project status review for the decision maker and project stakeholders. The review should address: (1) Requirements Analysis Phase activities status, (2) planning status for all subsequent life cycle phases (with significant detail on the next phase, to include the status of pending contract actions), (3) resource availability status, and (4) acquisition risk assessments of subsequent life cycle phases given the planned acquisition strategy.



QPM #

AQS 200-001-WI

Revision

1


6 PHASE 4: DESIGN PHASE

6.1. OBJECTIVEThe objective of the Design Phase is to transform the detailed, defined requirements into complete, detailed specifications for the system to guide the work of the Development Phase. The decisions made in this phase address, in detail, how the system will meet the defined functional, physical, interface, and data requirements. Design Phase activities may be conducted in an iterative fashion, producing first a general system design that emphasizes the functional features of the system, then a more detailed system design that expands the general design by providing all the technical detail.

6.2. TASKS AND ACTIVITIESThe following tasks are performed during the Design Phase. The tasks and activities actually performed depend on the nature of the project. Guidelines for selection and inclusion of tasks for the Design Phase may be found in Section 12, Alternative SDLC Work Patterns.

6.2.1. Establish the Application EnvironmentIdentify/specify the target environment, the development environment and the design environment.

6.2.2. Design the ApplicationIn the system design, first the general system characteristics are defined. The data storage and access for the database layer need to be designed. The user interface at the desktop layer needs to be designed. The business rules layer or the application logic needs to be designed. The interfaces from application to application and application to database also need to be designed and documented.

6.2.3. Select Information Security ControlsBased on the results of the system categorization (see Section 4.2.10) the security controls described in the preliminary security plan must be tailored to the system’s specific requirements. During the design phase, the development team should address each security requirement by selecting the specific controls to be implemented.

Note that there may be business reasons for failing to meet a particular security requirement, in which case these reasons must be documented in the Security Plan. However, the failure to meet a requirement also introduces a potential risk or vulnerability which should also be documented in the Risk Assessment.

The security plan should be updated to include a complete system characterization or description of the information system, based on the system design at this stage and the security controls that have been selected for implementation. Development Teams should consult NIST SP800-18, Guide for Developing Security Plans Information Technology Systems and SP800-53, Recommended Security Controls for Federal Information Systems for additional information on these topics.



QPM #

AQS 200-001-WI

Revision

1


6.2.4. Develop Contingency PlanDepending on the system criticality and sensitivity, the Contingency Plan for the system might be included as part of the Security Plan, or it might be a separate document. For mission-critical systems, a separate document is required.

The Contingency Plan describes how the system will be operated and maintained in the event that its confidentiality, availability, or integrity are harmed.

6.2.5. Develop System Design DocumentThe system design document will be developed by the project manager and project team, identifying the steps used in the design of the application/system. The System Design Document is a deliverable in the Design Phase. The AVS Enterprise Architecture should be referenced to determine if there are established constraints with regard to technical architecture that will impact design decisions.

(See Section 31, System Design Document).

6.2.6. Develop Maintenance ManualDevelop the maintenance manual to ensure continued operation of the system once it is completed. This is a deliverable in the Design Phase. (See Section 33, Maintenance Manual)

6.2.7. Develop Operations ManualDevelop the Operations Manual for mainframe systems/applications and the System Administrators Manual for client/server systems/applications. This is a deliverable in the Design Phase. (See Section 34, Operations Manual and Section 35, System Administration Manual)

6.2.8. Conduct Preliminary Design ReviewThis is an ongoing interim review of the system design as it evolves through the Design Phase. Detailed objective system functions, performance requirements, security requirements, and system platform characteristics will be reviewed.

6.2.9. Design Business ProcessesThe business organization, roles and procedures for designing this system/application need to be articulated.

6.2.10. Design Human Performance Support (Training)The Training Plan and the User Manual are created during the Design Phase. The training plan should be created in coordination with the AVS IT Training Program Manager. The Training Plan and User Manual are deliverable of the Design Phase. (See Section 36, Training Plan, and Section 37, User Manual)

6.2.11. Design Conversion/Migration/Transition StrategiesIf current information needs to be converted/migrated/transitioned to the new system, plans need to be designed for those purposes, especially if converting means re-engineering existing processes. The Conversion Plan, Implementation Plan and Contingency Plan need to be designed in this phase and are deliverables. (See Section 30, Conversion Plan, Section 32, Implementation Plan, and Section 29, Contingency Plan)



QPM #

AQS 200-001-WI

Revision

1


6.2.12. Revise Previous DocumentationDocuments from the previous phases need to be revised during the Design Phase. The updates should by signed off by the Project Manager for the Test Plan, VV&T Plan, System Security Plan, Security Risk Assessment, Project Management Plan, Configuration Management Plan, QA Plan, CBA, Risk Management Plan, ICD, CONOPS and the Test and Evaluation Master Plan. The following documents from previous phases should be updated and finalized during the Design Phase: FRD, Acquisition Plan, Privacy Act Federal Register Notice and the Records Disposition Schedule.

6.2.13. Develop Security Operating ProceduresDevelop procedures on how security will be handled throughout the Design Phase and who will be responsible for carrying out these procedures.

6.2.14. Conduct Final Design ReviewThe Project Manager and System Proponent conduct the final design review and approve/disapprove the project into the Development Phase. This review is conducted as the end of the Design Phase and confirms that modifications prompted by earlier reviews are incorporated.

6.3. ROLES AND RESPONSIBILITIESProject Manager. The project leader is responsible and accountable for the successful execution of the Design Phase. The project leader is responsible for leading the team that accomplishes the tasks shown above.

Project Team. The project team members (regardless of the organization of permanent assignment) are responsible for accomplishing assigned tasks as directed by the project manager.

Contracting Officer. The contracting officer is responsible and accountable for preparing solicitation documents under the guidance of the program manager.

ISSM. The ISSM is responsible for reviewing design documents to ensure that information security has been appropriately addressed.

AVS Enterprise Architect. The enterprise architect is responsible for providing corporate awareness of existing programs and assisting in the assessment of impact for changes or additions to the portfolio of programs managed by AVS for its customers.

AVS Information Technology Training Program Manager. The IT Training PM is responsible for coordinating the training requirements associated with the deployment and on-going operational education requirements for AVS applications.

Oversight Activities. Agency oversight activities, including the IRM office, provide advice and counsel to the project manager on the conduct and requirements of the Design Phase. Additionally, oversight activities provide information, judgments, and recommendations to the agency decision makers during project reviews and in support of project decision milestones.



QPM #

AQS 200-001-WI

Revision

1


6.4. DELIVERABLES, RESPONSIBILITIES, AND ACTIONSThe content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort. The system design document, system manuals, and various project plans are all described in the appendices of this manual.

6.4.1. Design DocumentThe Design Document describes the system requirements, operating environment, system and subsystem 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 Requirements Document (FRD), which is finalized in this phase, to provide a complete system specification of all user requirements for the system and reflects the user's perspective of the system design. Includes all information required for the review and approval of the project development. The sections and subsections of the design document may be organized, rearranged, or repeated as necessary to reflect the best organization for a particular project.

6.4.2. Maintenance ManualThe Maintenance Manual provides maintenance personnel with the information necessary to maintain the system effectively. The manual provides the definition of the software support environment, the roles and responsibilities of maintenance personnel, and the regular activities essential to the support and maintenance of program modules, job streams, and database structures. In addition to the items identified for inclusion in the Maintenance Manual, additional information may be provided to facilitate the maintenance and modification of the system. Appendices to document various maintenance procedures, standards, or other essential information may be added to this document as needed.

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

6.4.4. Training PlanThe Training Plan outlines the objectives, needs, strategy, and curriculum to be addressed when training users on the new or enhanced information system. The plan presents the 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. Training activities are developed to teach user personnel the use of the system as specified in the training criteria. Includes the target audience and topics on which training must be conducted on the list of training needs. It includes, in the training strategy, how the topics will be addressed and the format of the training program, the list of topics to be covered, materials, time, space requirements, and proposed schedules. The training plan should be created in coordination with the AVS IT Training Program Manager.



QPM #

AQS 200-001-WI

Revision

1


6.4.5. Conversion PlanThe Conversion Plan describes the strategies involved in converting data from an existing system to another hardware or software environment. It is appropriate to re-examine the original system's functional requirements for the condition of the system before conversion to determine if the original requirements are still valid.

6.4.6. Information System Security PlanThe ISSP includes complete documentation about the system architecture and design, the security controls that will be implemented, and how the security of the system will be maintained throughout its life cycle. This document should be almost final once the system design is complete, and will be finalized prior to production.

6.4.7. Contingency PlanThe Contingency Plan contains emergency response procedures; backup arrangements, procedures, and responsibilities; and post-disaster recovery procedures and responsibilities. Contingency planning is essential to ensure that AVS systems are able to recover from processing disruptions in the event of localized emergencies or large-scale disasters. It is an emergency response plan, developed in conjunction with application owners and maintained at the primary and backup computer installation to ensure that a reasonable continuity of support is provided if events occur that could prevent normal operations. Contingency plans shall be routinely reviewed, updated, and tested to enable vital operations and resources to be restored as quickly as possible and to keep system downtime to an absolute minimum. A Contingency Plan is synonymous with a disaster plan and an emergency plan. If the system/subsystem is to be located within a facility with an acceptable contingency plan, system-unique contingency requirements should be added as an annex to the existing facility contingency plan.

6.4.8. System Test and Evaluation PlanThis Plan will be written by the independent third party who will perform the Security Test and Evaluation, and should be in draft before the end of this phase. The Development Team should provide the third party with all system documentation prepared to date, including in particular the requirements and functional specifications, the Risk Assessment, and the Security Plan.

6.4.9. Implementation PlanThe Implementation Plan describes how the information system will be deployed and installed into an operational system. The plan contains an overview of the system, a brief description of the major tasks involved in the implementation, the overall resources needed to support the implementation effort (such as hardware, software, facilities, materials, and personnel), and any site-specific implementation requirements. This plan is updated during the Development Phase; the final version is provided in the Integration and Test Phase and used for guidance during the Implementation Phase.

6.4.10. Operations or Systems Administration ManualFor mainframe systems, the Operations Manual provides computer control personnel and computer operators with a detailed operational description of the information system and its associated environments, such as machine room operations and procedures. The Systems



QPM #

AQS 200-001-WI

Revision

1


Administration Manual serves the purpose of an Operations Manual in distributed (client/server) applications.

6.5. ISSUES FOR CONSIDERATION6.5.1. Project Decision IssuesThe decisions of this phase re-examine in greater detail many of the parameters addressed in previous phases. The design prepared in this phase will be the basis for the activities of the Development Phase. The overall objective is to establish a complete design for the system. The pre-requisites for this phase are the Project Plan, Functional Requirements Document, and Test Plan. A number of project approach, project execution, and project continuation decisions are made in this phase.

Project approach decisions include

Identifying existing or COTS components that can be used, or economically modified, to satisfy validated functional requirements.

Using appropriate prototyping to refine requirements and enhance user and developer understanding and interpretation of requirements.

Selecting specific methodologies and tools to be used in the later life cycle phases, especially the Development and Implementation Phases.

Determining how user support and training will be provided, how the remaining life cycle phases will be integrated, and newly identified risks and issues handled.

Project execution decisions include

Modifications that must be made to the initial information system need Modifications that will be made to current procedures Modifications that will be made to current systems/databases or to other

systems/databases under development How conversion of existing data will occur Project continuation decisions include The continued need of the information system to exist The continued development activities based on the needs addressed by the

design Availability of sufficient funding and other required resources for the remainder of

the systems life cycle

The system user community shall be included in the Design Phase actions as needed. It is also in the Design Phase that new or further requirements might be discovered that are necessary to accommodate individuals with disabilities. If so, these requirements shall be added to the FRD.

6.5.2. Security IssuesThe developer shall obtain the requirements from the System Security Plan and the FRD and allocate them to the specific modules within the design for enforcement purposes. For example, if a requirement exists to audit a specific set of user actions, the developer may have to add a workflow module into the design to accomplish the auditing.



QPM #

AQS 200-001-WI

Revision

1


Security operating procedures are guidance documents that provide users and administrators with detailed requirements on how to operate and maintain the system securely. They should address all applicable computer and telecommunications security requirements, including: system access controls; marking, handling, and disposing of magnetic media and hard copies; computer room access; account creation, access, protection, and capabilities; operational procedures; audit trail requirements; configuration management; processing area security; employee check-out; and emergency procedures. Security operating procedures may be created as separate documents or added as sections or appendices to the user and operations manuals. This activity should be conducted during the Design Phase.

6.5.3. Enterprise Architecture in DesignThe AQS-200 Enterprise Architecture should be used to determine if there are any design constraints documented that impact this phase of development. OMB Circular A-130 provides guidance that the architecture must include a Technical Reference Model (TRM) to identify and describe planned and existing information services (databases, communications, intranet, etc) used in the organization. It must also include a Standards Profile that defines the set of IT standards that support the services articulated in the TRM.

OMB guidance also includes linkage of Enterprise Architecture to Information Security. The architecture must include a Security Standards Profile (SSP). According to Circular A-130, the SSP “is specific to the security services specified in the EA and covers such services as identification, authentication, and non-repudiation; audit trail creation and analysis; access controls; cryptography management; virus protection; fraud prevention; detection and mitigation; and intrusion prevention and detection.

6.6. REVIEW ACTIVITY

This section describes the joint management reviews for both requirements and design that shall be held during the Design Phase. Prior to the design reviews, the acquirer shall have reviewed the deliverables initiated, updated, or completed during the Design Phase (see Section 6.4.1, Design Document).

6.6.1. Requirements ReviewsSystem/subsystem and software requirements reviews are held at the beginning of the Design Phase to resolve open issues regarding the specified requirements for a software system or subsystem.

6.6.2. Design ReviewsA system/subsystem design review is held at the end of the Design Phase to resolve open issues regarding one or more 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 Phase to resolve open

issues regarding one or more of the following: The software-wide design decisions



QPM #

AQS 200-001-WI

Revision

1


The architectural design of a software item Security controls The detailed design of a software item or portion thereof (such as a database)

Upon completion of all Design Phase tasks and receipt of resources for the next phase, the Project Manager, together with the project team should prepare and present a project status review for the decision maker and project stakeholders. The review should address: (1) Design Phase activities status, (2) planning status for all subsequent life cycle phases (with significant detail on the next phase, to include the status of pending contract actions), (3) resource availability status, and (4) acquisition risk assessments of subsequent life cycle phases given the planned acquisition strategy.



QPM #

AQS 200-001-WI

Revision

1


7 PHASE 5: DEVELOPMENT PHASE

7.1. OBJECTIVEThe objective of the Development Phase will be to convert the deliverables of the Design Phase into a complete information system. Although much of the activity in the Development Phase addresses the computer programs that make up the system, this phase also puts in place the hardware, software, and communications environment for the system and other important elements of the overall system.

The activities of this phase translate the system design produced in the Design Phase into a working information system capable of addressing the information system requirements. The development phase contains activities for requirements analysis, design, coding, integration, testing, and installation and acceptance related to software products. At the end of this phase, the system will be ready for the activities of the Integration and Test Phase.

7.2. TASKS AND ACTIVITIES7.2.1. Process ImplementationThis activity consists of several tasks that are the responsibility of the developer. The developer shall place the outputs under the Configuration Management Process and perform change control in accordance with it. The developer shall also document and resolve problems and non-conformances found in the software products and tasks.

The developer shall select, tailor, and use those standards, methods, tools, and computer programming languages that are documented, appropriate, and established by the organization for performing the activities of the Development Process.

Plans for conducting the activities of the development phase should be developed, documented and executed. The plans should include specific standards, methods, tools, actions, and responsibility associated with the development and qualification of all requirements including safety and security. Separate plans may be developed. The detailed project Work Breakdown Structure developed during the Planning Phase should be expanded to incorporate the WBS structure into each module or software configuration item to be developed.

7.2.2. System Requirements AnalysisAnalyze the intended use of the system to be developed to specify the system requirements. The system requirements specification shall describe the functions and capabilities of the system; the business, organizational and user requirements; the safety, security, human-factors engineering (ergonomics), interface, operations, and maintenance requirements; the design constraints and qualification requirements. The system requirements specification shall be documented.

Evaluate the system requirements using the criteria listed below. The results of evaluations shall be documented with respect to:

traceability to acquisition needs consistency with acquisition needs



QPM #

AQS 200-001-WI

Revision

1


testability feasibility of system architectural design feasibility of operation and maintenance degree of security assurance required

7.2.3. System Architectural DesignEstablish a top-level architecture of the system and document it. The architecture shall identify items of hardware, software, and manual-operations. All the system requirements should be allocated among the hardware configuration items, software configuration items, and manual operations.

Evaluate the system architecture and the requirements for the above items using the criteria listed below. Document the results.

traceability to the system requirements consistency with the system requirements appropriateness of design standards and methods used feasibility of the software items fulfilling their allocated requirements feasibility of operation and maintenance conformance to the AQS-200 AS-IS and TO-BE enterprise architectures

7.2.4. Software Requirements AnalysisEstablish and document software requirements, including the quality characteristics specifications, described below.

functional and capability specifications, including performance, physical characteristics, and environmental conditions under which the software item is to perform;

interfaces external to the software item; qualification requirements safety specifications, including those related to methods of operation and

maintenance, environmental influences, and personnel injury; security specifications, including those related to compromise of sensitive

information; human-factors engineering (ergonomics), including those related to manual

operations, human-equipment interactions, constraints on personnel, and areas needed concentrated human attention, that are sensitive to human errors and training;

data definition and database requirements; installation and acceptance requirements of the delivered software product at the

operation and maintenance site(s); user documentation user operation and execution requirements user maintenance requirements



QPM #

AQS 200-001-WI

Revision

1


Evaluate the software requirements using the criteria listed below and document them.

traceability to system requirements and system design external consistence with system requirements internal consistency testability feasibility of software design feasibility of operation and maintenance

Conduct joint reviews. Joint reviews are at both project management and technical levels and are held throughout the life of the contract. This process may be employed by any two parties, where one party (reviewing party) reviews another party (reviewed party).

7.2.5. Software Architectural DesignTransform the requirements for the software item into an architecture that describes its top-level structure and identifies the software components. Ensure that all the requirements for the software item are allocated to its software components and further refined to facilitate detailed design.

Develop and document a top-level design for the interfaces external to the software item and between the software components of the software item.

Develop and document a top-level design for the database.

Develop and document preliminary versions of user documentation.

Develop and document preliminary test requirements and the schedule for Software Integration.

Evaluate the architecture of the software item and the interface and database designs using the criteria listed below.

traceability to the requirements of the software item external consistency with the requirements of the software item internal consistency between the software components; appropriateness of design methods and standards used feasibility of detailed design feasibility of operation and maintenance


7.2.6. Software Detailed DesignDevelop a detailed design for each software component of the software item, including security components. The software components shall be refined into lower levels containing software units that can be coded, compiled, and tested. Ensure that all the software requirements are allocated from the software components to software units.



QPM #

AQS 200-001-WI

Revision

1


Develop and document a detailed design for the interfaces external to the software item, between the software components, and between the software units. The detailed design of the interfaces shall permit coding without the need for further information.

Develop and document a detailed design for the database.

Develop and document in the Security Plan a comprehensive list of security requirements and the corresponding controls.

Update user documentation as necessary.

Define and document test requirements and schedule for testing software units. The test requirements should include stressing the software unit at the limits of its requirements.

Update the test requirements and the schedule for Software Integration.

Evaluate the software detailed design and test requirements considering the criteria listed below.

traceability to the requirements of the software item external consistence with architectural design internal consistency between software components and software units appropriateness of design methods and standards used feasibility of testing feasibility of operation and maintenance


7.2.7. Software Coding and TestingDevelop and document each software unit and database as well as test procedures and data for testing each software unit and database.

Test each software unit and database ensuring that it satisfies its requirements. Document the results.

Ensure that test plans requiring independent third-party validation, such as System Test and Evaluation, are carried out and that the results are incorporated into coding as necessary to correct security issues.

Update the user documentation as necessary.

Update the test requirements and the schedule for Software Integration.

Evaluate software code and test results considering the criteria listed below.

traceability to the requirements and design of the software item external consistency with the requirements and design of the software item internal consistency between unit requirements test coverage of units appropriateness of coding methods and standards used



QPM #

AQS 200-001-WI

Revision

1


feasibility of software integration and testing feasibility of operation and maintenance

7.2.8. Software IntegrationDevelop an integration plan to integrate the software units and software components into the software item. The plan shall include test requirements, procedures, data, responsibilities, and schedule.

Integrate the software units and software components and test as the aggregates are developed in accordance with the integration plan. It shall be ensured that each aggregate satisfies the requirements of the software item and that the software item is integrated at the conclusion of the integration activity.


Develop and document, for each qualification requirement of the software item, a set of tests, test cases (inputs, outputs, test criteria), and test procedures for conducting software Qualification Testing. Ensure that the integrated software item is ready for Software Qualification Testing.

Evaluate the integration plan, design, code, tests, test results, and user documentation considering the criteria listed below.

traceability to the system requirements external consistency with the system requirements internal consistency test coverage of the requirements of the software item appropriateness of test standards and methods used conformance to expected results feasibility of software qualification testing feasibility of operation and maintenance


7.2.9. Software Qualification TestingConduct qualification testing in accordance with the qualification requirements for the software item. Ensure that the implementation of each software requirement is tested for compliance.


Evaluate the design, code, tests, test results, and user documentation considering the criteria listed below.

test coverage of the requirements of the software item conformance to expected results feasibility of system integration and testing, if conducted feasibility of operation and maintenance



QPM #

AQS 200-001-WI

Revision

1


Support audit(s) which could be conducted to ensure that:

as-coded software products (such as software item) reflect the design documentation

the acceptance review and testing requirements prescribed by the documentation are adequate for the acceptance of the software products

test data comply with the specification software products were successfully tested and meet their specifications test reports are correct and discrepancies between actual and expected results

have been resolved user documentation complies with standards as specified activities have been conducted according to applicable requirements, plans and

contract the costs and schedules adhere to the established plans

The results of the audits shall be documented. If both hardware and software are under development or integration, the audits may be postponed until the System Qualification Testing.

Upon successful completion of the audits, if conducted, update and prepare the deliverable software product for System Integration, System Qualification Testing, Software Installation, or Software Acceptance Support as applicable. Also, establish a baseline for the design and code of the software item.

7.2.10. System IntegrationIntegrate the software configuration items with hardware configuration items, manual operations, and other systems as necessary, into the system. The aggregates shall be tested, as they are developed, against their requirements. The integration and the test results shall be documented.

For each qualification requirement of the system, a set of tests, test cases (inputs, outputs, test criteria), and test procedures for conducting System Qualification Testing shall be developed and documented. Ensure that the integrated system is ready for System Qualification Testing.

Evaluate the integrated system considering the criteria listed below. The results of the evaluations shall be documented.

test coverage of system requirements appropriateness of test methods and standards used conformance to expected results feasibility of system qualification testing feasibility of operation and maintenance

7.2.11. System Qualification TestingConduct system qualification testing in accordance with the qualification requirements specified for the system. Ensure that the implementation of each system requirement is tested for



QPM #

AQS 200-001-WI

Revision

1


compliance and that the system is ready for delivery. The qualification testing results shall be documented.

Evaluate and document the system considering the criteria listed below.

test coverage of system requirements conformance to expected results feasibility of operation and maintenance

The developer shall support audits. The results of the audits shall be documented.

Upon successful completion of the audits, if conducted, update and prepare the deliverable software product for Software Installation and Software Acceptance Support. Also establish a baseline for the design and code of each software configuration item.

7.2.12. Software InstallationDevelop a plan to install the software product in the target environment as designed. The resources and information necessary to install the software product shall be determined and be available. The developer shall assist the acquirer with the set-up activities. Where the installed software product is replacing an existing system, the developer shall support any parallel running activities that are required. The installation plan shall be documented.

Install the software product in accordance with the installation plan. Ensure that the software code and databases initialize, execute, and terminate as specified in the contract. The installation events and results shall be documented.

7.2.13. Software Acceptance SupportSupport the acquirer's acceptance review and testing of the software product. Acceptance review and testing shall consider the results of the Joint Reviews, Audits, Software Qualification Testing, and System Qualification Testing (if performed). The results of the acceptance review and testing shall be documented.

The developer shall complete and deliver the software product as specified.

The developer shall provide initial and continuing training and support to the acquirer as specified.

7.3. ROLES AND RESPONSIBILITIESProject Manager. The project leader is responsible and accountable for the successful execution of the Development Phase. The project leader is responsible for leading the team that accomplishes the tasks shown above.

Project Team. The project team members (regardless of the organization of permanent assignment) are responsible for accomplishing assigned tasks as directed by the project manager.

Contracting Officer. The contracting officer is responsible and accountable for preparing solicitation documents under the guidance of the program manager.

ISSM. The ISSM is responsible for ensuring that information security testing and deliverables adequately comply with appropriate requirements and guidance.



QPM #

AQS 200-001-WI

Revision

1


AQS-200 Enterprise Architect. The enterprise architect is responsible for providing corporate awareness of existing programs and assisting in the assessment of impact for changes or additions to the portfolio of programs managed by AQS-200 for its customers.

Oversight Activities. Agency oversight activities, including the IRM office, provide advice and counsel to the project manager on the conduct and requirements of the Development Phase. Additionally, oversight activities provide information, judgments, and recommendations to the agency decision makers during project reviews and in support of project decision milestones.

7.4. DELIVERABLES, RESPONSIBILITIES AND ACTIONSThe content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort. The following deliverables shall be initiated during the Development Phase:

7.4.1. Software Development DocumentContains documentation pertaining to the development of each unit or module, including the test cases, software, test results, approvals, and any other items that will help explain the functionality of the software

7.4.2. System (Application) SoftwareUsed for the Test Phase and finalized in this phase before implementation of the system Include the disks (or other medium) used to store the information.

7.4.3. Test Files/DataUsed for system testing. Provide the actual test data and files used.

7.4.4. Integration DocumentThis will explain how the software components, hardware components, or both are combined and the interaction between them.

7.4.5. Test Analysis ReportThis is the formal documentation of the software testing as defined in the Test Report.

7.4.6. System Security Test and Evaluation ReportResults of security testing that were carried out during this phase should be documented separately.

7.4.7. Periodic Progress ReportsProgress reports which compare actual to planned accomplishments should be provided on a regular basis. The Work Breakdown Structure will serve as the basis for this report. The frequency of the progress report can vary based on the size and complexity of the project, but both time and dollars should have a budgeted versus actual comparison. If the project is complex, involving many developers and interrelated components, project-planning software should be used with the capability of showing how budget variances affect the critical path.

7.5. ISSUES FOR CONSIDERATIONThere are three phase prerequisites that should be completed before beginning this phase.



QPM #

AQS 200-001-WI

Revision

1


Project management plan and schedule indicating target date for completion of each module and target date for completion of system testing.

System design document, containing program logic flow, identifying any existing code to be used, and the subsystems with their inputs and outputs.

Unit/module and integration test plans, containing testing requirements, schedules, and test case specifications for unit and integration testing.

7.5.1. Enterprise Architecture in DevelopmentBy this phase, the application should be fully documented in the TO-BE and/or AS-IS AQS-200 Enterprise Architecture. Information Flows, Data Relationships, alignment to business processes and strategic initiatives have been validated and established. With regard to Enterprise Architecture, the main consideration during this phase is to ensure conformance to the established plan coordinated with the AQS-200 Enterprise Architect. Any changes in design should trigger a check of the AQS-200 architecture to ensure conformance with existing and planned architecture constraints.

7.6. REVIEW ACTIVITYUpon completion of all Development Phase tasks and receipt of resources for the next phase, the Project Manager, together with the project team should prepare and present a project status review for the decision maker and project stakeholders. The review should address: (1) Development Phase activities status, (2) planning status for all subsequent life cycle phases (with significant detail on the next phase, to include the status of pending contract actions), (3) resource availability status, and (4) acquisition risk assessments of subsequent life cycle phases given the planned acquisition strategy.



QPM #

AQS 200-001-WI

Revision

1


8 PHASE 6: INTEGRATION AND TEST PHASE

8.1. OBJECTIVEThe objective of this phase is to prove that the developed system satisfies the requirements defined in the FRD. Another purpose is to perform an integrated system test function as specified by the design parameters. This function shall be the responsibility of the system testers and will be heavily supported by the user participants.

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

Several types of tests will be conducted in this phase. First, subsystem integration tests shall be executed and evaluated by the development team to prove that the program components integrate properly into the subsystems and that the subsystems integrate properly into an application. Next, the testing team conducts and evaluates system tests to ensure the developed system meets all technical requirements, including performance requirements. Next, the testing team and the Security Program Manager conduct security tests to validate that the access and data security requirements are met. Finally, users participate in acceptance testing to confirm that the developed system meets all user requirements as stated in the FRD. Acceptance testing shall be done in a simulated "real" user environment with the users using simulated or real target platforms and infrastructures.

8.2. TASKS AND ACTIVITIESThe tasks and activities actually performed depend on the nature of the project. Guidelines for selection and inclusion of tasks for the Integration and Test Phase may be found in Chapter 13, Alternate SDLC Work Patterns. The following tasks should be completed during the Integration and Test phase.

8.2.1. Start Test PhaseThe test and evaluation team is responsible for establishing the test team and creating the test files/data.

8.2.2. Conduct Subsystem/System TestingThe test and evaluation team is responsible for creating/loading the test database(s) and executing the system test(s). All results should be documented on the Test Analysis Report (Appendix C-28), Test Problem Report (Appendix C-30) and on the Test Analysis Approval Determination (Appendix C-29). Any failed components should be migrated back to the development phase for rework, and the passed components should be migrated ahead for security testing.

8.2.3. Conduct Security TestingThe test and evaluation team will again create or load the test database(s) and execute security test(s), which may include penetration testing for highly critical or sensitive systems. All tests will be documented, similar to those above. Failed components will be migrated back to the



QPM #

AQS 200-001-WI

Revision

1


development phase for rework, and passed components will be migrated ahead for acceptance testing.

8.2.4. Conduct Acceptance TestingThe test and evaluation team will create/load the test database(s) and execute the acceptance test(s). All tests will be documented, similar to those above. Failed components will be migrated back to the development phase for rework, and passed components will migrate ahead for implementation.

8.2.5. Revise Previous Phase DocumentationDuring this phase, the Systems Technical Lead or the Developers will finalize the Software Development Document from the Development Phase. He/They will also finalize the Operations or Systems Administration Manual, User Manual, Training Plan, Maintenance Manual, Conversion Plan, Implementation Plan, Contingency Plan and Update the Interface Control Document from the Design Phase. The Project Manager should finalize the System Security Plan and the Security Risk Assessment from the Requirements Analysis Phase and the Project Management Plan from the Planning Phase. The Configuration Manager should finalize the Configuration Management Plan from the Planning Phase. The Quality Assurance office/person should finalize the Quality Assurance Plan from the Planning Phase. And finally, the Project Manager should finalize the Cost Benefit Analysis and the Risk Management Plan from the System Concept Development Phase.

8.3. ROLES AND RESPONSIBILITIESProject Manager: The project leader is responsible and accountable for the successful execution of the Integration and Test Phase. The project leader is responsible for leading the team that accomplishes the tasks shown above.



ISSM. The ISSM is responsible for reviewing Certification and Accreditation documentation and for coordinating review by others as appropriate.


Oversight Activities: Agency oversight activities, including the IRM office, provide advice and counsel for the project manager on the conduct and requirements of the Integration and Test Phase. Additionally, oversight activities provide information, judgments, and recommendations to the agency decision makers during project reviews and in support of project decision milestones.

8.4. DELIVERABLES, RESPONSIBILITIES, AND ACTIONSThe following deliverables shall be initiated during the Integration and Test Phase:



QPM #

AQS 200-001-WI

Revision

1


8.4.1. Test Analysis Approval DeterminationAttached to the test analysis report as a final result of the test reviews and testing levels above the integration test; briefly summarizes the perceived readiness for migration of the software

8.4.2. Test Problem ReportsDocument problems encountered during testing; the form is attached to the test analysis reports

8.4.3. IT Systems Security Certification & AccreditationThe information security documents produced to date are needed to obtain certification and accreditation of an information system. The documents should be collected together into a single package, called a Security Certification and Accreditation Package (SCAP). These documents are the Risk Assessment; System Security Plan; Contingency Plan (if separate), and Security Test and Evaluation Plans and Results. If additional security documentation has been prepared, such as a Security Features User's Guide, these may also be included in the SCAP. The SCAP Signature page can be developed at this time and included in the SCAP package. Consult the AQS-200 Information System Security Manager for document formats.

The FAA requires that a hard-copy of the SCAP be delivered to the Office of Information Security (AIS). Thus, when the SCAP has been completed just prior to production, the Project Manager should prepare a binder with the appropriate hard copies, and should work with the ISSM to ensure appropriate delivery.

8.5. ISSUES FOR CONSIDERATION8.5.1. SecuritySecurity controls shall be tested before system implementation to uncover all design and implementation flaws that would violate security policy. Security Test and Evaluation (ST&E) involves determining a system's security mechanisms adequacy for completeness and correctness, and the degree of consistency between system documentation and actual implementation. This will be performed by an independent third party, who will use a variety of assurance methods such as analysis of system design documentation, inspection of test documentation, and independent execution of function testing and penetration testing. Results of the ST&E affect security activities developed earlier in the life cycle, such as the security risk assessment, system security plan, and contingency plan. Each of these activities will be updated in this phase based on the results of the ST&E.

8.5.2. Enterprise Architecture in Integration & TestingDuring the Integration and Testing phase, documentation associated with the program is finalized. Any changes impacting information stored in the AQS-200 architecture should be brought to the AQS-200 Enterprise Architect for coordination and reporting in the AQS-200 architecture. Depending on the architectural approach at the time, there may be direct linkages created from the Enterprise Architecture to the specific program documents.



QPM #

AQS 200-001-WI

Revision

1


8.6. REVIEW ACTIVITYUpon completion of all Integration and Test Phase tasks and receipt of resources for the next phase, the Project Manger, together with the project team should prepare and present a project status review for the decision maker and project stakeholders. The review should address: (1) Integration and Test Phase activities status, (2) planning status for all subsequent life cycle phases (with significant detail on the next phase, to include the status of pending contract actions), (3) resource availability status, and (4) acquisition risk assessments of subsequent life cycle phases given the planned acquisition strategy.



QPM #

AQS 200-001-WI

Revision

1


9 PHASE 7: IMPLEMENTATION PHASE

9.1. OBJECTIVEIn this phase, the system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. Activities in this phase include notification of implementation to end users, execution of the previously defined training plan, data entry or conversion, final system test and evaluation in the production environment, completion of security certification and accreditation and post implementation evaluation. This phase continues until the system is operating in production in accordance with the defined user requirements.

The new system can fall into three categories, replacement of a manual process, replacement of a legacy system, or upgrade to an existing system. Regardless of the type of system, all aspects of the implementation phase should be followed. This will ensure the smoothest possible transition to the organization's desired goal.

9.2. TASKS AND ACTIVITIESTasks and activities in the implementation phase are associated with certain deliverables described in section 9.4. The tasks and activities actually performed depend on the nature of the project. Guidelines for selection and inclusion of tasks for the Implementation Phase may be found in Section 12, Alternative SDLC Work Patterns. A description of these tasks and activities is provided below.

9.2.1. Notification of ImplementationThe implementation notice should be sent to all users and organizations affected by the implementation. Additionally, it is good policy to make internal organizations not directly affected by the implementation aware of the schedule so that allowances can be made for a disruption in the normal activities of that section. Some notification methods are email, internal memo to heads of departments, and voice tree messages. 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;

and The process to obtain system support, including contact names and phone

numbers.

9.2.2. Execution of Training PlanIt is always a good business practice to provide training before the end user uses the new system. Because there has been a previously designed training plan established, complete with the system user manual, the execution of the plan should be relatively simple. Typically what prevents a plan from being implemented is lack of funding. Good budgeting should prevent this from happening.



QPM #

AQS 200-001-WI

Revision

1


9.2.3. Data Entry or ConversionWith the implementation of any system, typically there is old data which is to be included in the new system. This data can be in a manual or an automated form. Regardless of the format of the data, the tasks in this section are two fold, data input and data verification. When replacing a manual system, hard copy data will need to be entered into the automated system. Some sort of verification that the data is being entered correctly should be conducted throughout this process. This is also the case in data transfer, where data fields in the old system may have been entered inconsistently and therefore affect the integrity of the new database. Verification of the old data becomes imperative to a useful computer system.

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

9.2.4. Install SystemTo ensure that the system is fully operational, install the system in a production environment.

9.2.5. Final System Test and Evaluation (ST&E)The final ST&E cannot be performed until the system is in the production environment. This is to ensure that the production implementation has not introduced any new, previously unquantified risks. The results of this test are documented, and the final Risk Assessment and Security Plans are updated with the results.

9.2.6. Plan of Action and Milestones (POA&M)In the Risk Assessment, there will be two types of risks described. The first is those that are acceptable (generally because the risk is very low) and that will be managed as described in the ISSP. The second type of risk is that which is unacceptable in the AQS-200 environment. After conferring with the ISSM, AVS-1 (the Designated Approving Authority), makes the decision about what risk is unacceptable.

Even if there are legitimate business reasons for allowing unacceptable risk to carry over into production, the system owner must nonetheless agree to correct the risk as soon as feasible. He or she does this by creating a Plan of Action and Milestones which lists each security weakness or risk in the system, the specific steps that need to be taken for correction, the resources required to make the correction, and the schedule for correction.

9.2.7. Completion of Security Certification and AccreditationThe SCAP binder prepared during the previous phase should be updated with the final Risk Assessment, Security Plan, ST&E Results, and POA&M if there is one. Only when the previous items are completed should a system be accredited. The systems security plan and certification/accreditation package should be prepared prior to system use, and triennially thereafter. The System Owner and IT Project Manager should affix their signatures on the Signature Page, and the package delivered to the Information Systems Security Manager for final review, certification, and accreditation.



QPM #

AQS 200-001-WI

Revision

1


9.2.8. Report System as Operational in the Enterprise ArchitectureThe system should be reported as operational to the AQS-200 Enterprise Architecture. At the same time, the representation of the system in the enterprise architecture should be reviewed for completeness and accuracy.

9.2.9. Post-Implementation EvaluationAfter the system has been fielded a post-implementation evaluation is conducted to determine the success of the project through its implementation phase. The purpose of this evaluation is to document implementation experiences to recommend system enhancements and provide guidance for future projects.

In addition, change implementation notices will be utilized to document user requests for fixes to problems that may have been recognized during this phase. It is important to document any user request for a change to a system to limit misunderstandings between the end user and the system programmers.

9.2.10. Review Previous DocumentationDuring this phase, the ICD is revised from the Requirements Analysis Phase. The CONOPS, System Security Plan, Security Risk Assessment, Software Development Document, System Software and the Integration Document are also revised and finalized during the Implementation Phase.

9.3. ROLES AND RESPONSIBILITIESProject Manager: The project leader is responsible and accountable for the successful execution of the Implementation Phase. The project leader is responsible for leading the team that accomplishes the tasks shown above.



ISSM. The ISSM is responsible for overseeing delivery of the final C&A documentation.


Oversight Activities: Agency oversight activities, including the IRM office, provide advice and counsel for the project manager on the conduct and requirements of the Implementation Phase. Additionally, oversight activities provide information, judgments, and recommendations to the agency decision makers during project reviews and in support of project decision milestones.

9.4. DELIVERABLES, RESPONSIBILITIES, AND ACTIONSThe deliverables described below are initiated during the Implementation Phase.



QPM #

AQS 200-001-WI

Revision

1


9.4.1. Delivered SystemAfter the Implementation Phase Review and Approval Certification is signed by the Project Manager and the System Proponent representative, the system - including the production version of the data repository - is delivered to the customer for the Operations and Maintenance Phase.

9.4.2. SCAP BinderThe final SCAP Binder (for delivery to AIS) should include the signature page, Risk Assessment, Security Plan, Contingency Plan, and System Test and Evaluation Results.

9.4.3. Change Implementation NoticeA formal request and approval document for changes made during the Implementation Phase.

9.4.4. Version Description DocumentThe primary configuration control document used to track and control versions of software released to the operational environment. It is a summary of the features and contents for the software build, and identifies and describes the version of the software being delivered.

9.4.5. Post-Implementation Review ReportThis report is created at the end of the Implementation Phase. It is conducted to ensure that the system functions as planned and expected; to verify that the system cost is within the estimated amount; and to verify that the intended benefits are derived as projected.

9.5. ISSUES FOR CONSIDERATION

9.5.1. SecurityTwo of the most important security risk management activities within AQS-200 are certification and accreditation. During this phase of the SDLC, it is important that the documentation about security activities that took place earlier is updated, and that this documentation be forwarded into the formal Certification and Accreditation process as described above. FAA policy requires that all systems be accredited before moving into production.

9.5.2. Enterprise Architecture during ImplementationWhen the program officially moves from development to production mode, it should be reported to the AQS-200 Enterprise Architect. The architecture reflects AS-IS and TO-BE states of the AQS-200 environment. As applications transition from development, to production, and to retirement, their status is reflected in the architecture.

9.6. REVIEW ACTIVITYA post-implementation review shall be conducted to ensure that the system functions as planned and expected; to verify that the system cost is within the estimated amount; and to verify that the intended benefits are derived as projected. Normally, this shall be a one-time review, and it occurs after a major implementation; it may also occur after a major enhancement



QPM #

AQS 200-001-WI

Revision

1


to the system. The results of an unacceptable review are submitted to the System Proponent for its review and follow-up actions. The System Proponent may decide it will be necessary to return the deficient system to the responsible system development Project Manager for correction of deficiencies.

During the Implementation Phase Review, recommendations may be made to correct errors, improve user satisfaction or improve system performance. For contractor development, analysis shall be performed to determine if additional activity is within the scope of the statement of work or within the original contract. An Implementation Phase Review and Approval Certification should be signed off by the Project Manager and System Proponent representative to verify the acceptance of the delivered system by the System Proponent.

The Implementation Phase-End Review shall be organized, planned, and led by the Project Quality Assurance representative.



QPM #

AQS 200-001-WI

Revision

1


10 PHASE 8: OPERATIONS AND MAINTENANCE PHASE

10.1. OBJECTIVEMore than half of the life cycle costs are attributed to the operations and maintenance of systems. In this phase, it is essential that all facets of operations and maintenance are performed. The system is being used and scrutinized to ensure that it meets the needs initially stated in the planning phase. Problems are detected and new needs arise. This may require modification to existing code, new code to be developed and/or hardware configuration changes. Providing user support is an ongoing activity. New users will require training and others will require training as well. The emphasis of this phase will be to ensure that the users’ needs are met and the system continues to perform as specified in the operational environment. Additionally, as operations and maintenance personnel monitor the current system they may become aware of better ways to improve the system and therefore make recommendations. Changes will be required to fix problems, possibly add features and make improvements to the system. This phase will continue as long as the system is in use.

10.2. TASKS AND ACTIVITIES10.2.1. Systems OperationsOperations support is an integral part of the day-to-day operations of a system. In small systems, the same person may do all or part of each task. But in large systems, each function may be done by separate individuals or even separate areas. The Operations Manual is developed in previous SDLC phases. This document defines tasks, activities and responsible parties and will need to be updated as changes occur. Systems operations activities and tasks need to be scheduled, on a recurring basis, to ensure that the production environment is fully functional 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 available during the defined hours of Operations;

Implement non-emergency requests during scheduled Outages, as prescribed in the Operations Manual;

Ensure all processes, manual and automated, are documented in the operating procedures. These processes should comply with the system documentation;

Acquisition and storage of supplies (i.e. paper, toner, tapes, removable disk); Perform backups (day-to-day protection, contingency); Perform the physical security functions including ensuring adequate UPS,

Personnel have proper security clearances and proper access privileges etc.; Ensure contingency planning for disaster recovery is current and tested ; Ensure users are trained on current processes and new processes; Ensure that service level objectives are kept accurate and are monitored; Maintain performance measurements, statistics, and system logs. Examples of

performance measures include volume and frequency of data to be processed in each mode, order and type of operations;



QPM #

AQS 200-001-WI

Revision

1


Ensure that security patches are monitored and applied regularly; Monitor the performance statistics, report the results and escalate problems

when they occur.

10.2.2. Data / Software AdministrationData / Software Administration is needed to ensure that input data and output data and databases are correct and continually checked for accuracy and completeness. This includes insuring that any regularly scheduled jobs are submitted and completed correctly. Software and databases should be maintained at (or near) the current maintenance level. The backup and recovery processes for databases are normally different than the day-to-day DASD volume backups. The backup and recovery process of the databases should be done as a Data / Software Administration task. A checklist of Data / Software Administration tasks and activities are:

Performing a periodic Verification / Validation of data, correct data related problems;

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

Interfacing with other functional areas for Day-to-day checking / corrections; Installing, configuring, upgrading and maintaining data base(s). This includes

updating processes, data flows, and objects (usually shown in diagrams); Developing and performing data / data base backup and recovery routines for

data integrity and recoverability. Ensure documented properly in the Operations Manual;

Developing and maintaining a performance and tuning plan for online process and data bases;

Performing configuration/design audits to ensure software, system, parameter configuration are correct.

10.2.3. Problem and Modification ProcessOne fact of life with any system is that change is inevitable. Users need an avenue to suggest change and identified problems. A User Satisfaction Review (Section 47) that can include a Customer Satisfaction Survey, can be designed and distributed to obtain feedback on operational systems to help determine if the systems are accurate and reliable. Systems administrators and operators need to be able to make recommendations for upgrade of hardware, architecture and streamlining processes. For small in-house systems, an in-house process can handle modification requests. For large integrated systems, modification requests may be addressed in the Requirements document and may take the form of a change package or a formal Change Implementation Notice (Section 43) and may require justification and cost benefits analysis for approval by a review board. The Requirements document for the project may call for a modification cut-off and rollout of the system as a first version and all subsequent changes addressed as a new or enhanced version of the system. A request for modifications to a system may also generate a new project and require a new project initiation plan.



QPM #

AQS 200-001-WI

Revision

1


10.2.4. System / Software MaintenanceDaily operations of the system software may necessitate that maintenance personnel identify potential modifications needed to ensure that the system continues to operate as intended and produces quality data. Daily maintenance activities for the system, takes place to ensure that any previously undetected errors are fixed, including those that may be related to information security issues. Maintenance personnel may determine that modifications to the system and databases are needed to resolve errors or performance problems. Also modifications may be needed to provide new capabilities or to take advantage of hardware upgrades or new releases of system software and application software used to operate the system. New capabilities may take the form of routine maintenance or may constitute enhancements to the system or database as a response to user requests for new/improved capabilities. New capabilities needs may begin a new problem modification process described above.

At this phase of the SDLC all security activities have been at least initiated or completed. An update must be made to the Sensitive System Security plan; an update and test of the contingency plan should be completed. Continuous vigilance should be given to virus and intruder detection. The Project Manager must be sure that security operating procedures are kept updated accordingly.

10.2.5. Review Previous DocumentationReview and update documentation from the previous phases. In particular, the Operations Manual, SBD and Contingency Plan need to be updated and finalized during the Operations and Maintenance Phase, and the SCAP documentation must be maintained in a status that accurately reflects the system’s security posture.

10.3. ROLES AND RESPONSIBILITIESThis list briefly outlines some of the roles and responsibilities for key maintenance personnel. Some roles may be combined or eliminated depending upon the size of the system to be maintained. Each system will dictate the necessity for the roles listed below.

Systems Manager: The Systems Manager develops documents and executes plans and procedures for conducting activities and tasks of the Maintenance Process. To provide for an avenue of problem reporting and customer satisfaction, the Systems Manager should create and discuss communications instructions with the systems customers. Systems Managers should keep the Help Desk Personnel informed of all changes to the system especially those requiring new instructions to users.

Technical Support: Personnel that proved technical support to the program. This support may involve granting access rights to the program, setup of workstations or terminals to access the system, or maintaining the operating system for both server and workstation. Technical support personnel may be involved with issuing user ids or login names and passwords. In a Client server environment technical support may perform systems scheduled backups and operating system maintenance during downtime.

Vendor Support: The technical support and maintenance on some programs are provided through vendor support. A contract is established outlining the contracted systems administration, operators, and maintenance personnel duties and responsibilities. One



QPM #

AQS 200-001-WI

Revision

1


responsibility that should be included in the contract is that all changes to the system will 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 changes or modifications to the system. Help Desk Personnel are contacted by the user when questions or problems occur with the daily operations of the system. Help Desk Personnel need to maintain a level of proficiency with the system.

Operations or Operators: For many mainframe systems, technical support for a program is provided by an operator. The operator performs scheduled backup, performs maintenance during downtime and is responsible to ensure the system is online and available for users. Operators may be involved with issuing user ids or login names and passwords for the system.

Customers: The customer needs to be able to share with the systems manager the need for improvements or the existence of problems. Some users live with a situation or problem because they feel they must. Customers may feel that change will be slow or disruptive. Some feel the need to create workarounds. A customer has the responsibility to report 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 Application Design sessions. Analysts programs for errors, debugs the program and tests program design.

Process Improvement Review Board: A board of individuals may be convened to approve recommendations for changes and improvements to the system. This group may be chartered. The charter should outline what 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 share knowledge they have gained concerning a program or system. They usually meet to exchange information, share programs and can provide expert knowledge for a system under consideration for change.

Contracting Officer Technical Representative (COTR): The COTR has many responsibilities when a contract has been awarded for maintenance of a program. The COTR should have a certificate of training for completion of a COTR course. The COTR’s main role is to make sure that the interests of the Contracting Office are protected and that no modifications are made to the contract without permission from the Contracting office.

Data Administrator: The Data Administrator performs tasks that ensure that accurate and valid data are entered into the system. Sometimes this person creates the information systems database, maintains the databases security and develops plans for disaster recovery. The data administrator may be called upon to create queries and reports for a variety of user requests. The data administrator responsibilities include maintaining the databases data dictionary. The data dictionary provides a description of each field in the database, the field characteristics and what data is maintained with the field.

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



QPM #

AQS 200-001-WI

Revision

1


ISSM: The ISSM will ensure that certification and accreditation reviews take place every three years, as required by federal legislation. Further, the ISSM will ensure that annual self-assessments are completed. The ISSM may be asked to review system change requests, review Change Impact Assessments, participate in the Configuration Control Board process, and conduct and report changes that may be made that affect the security posture of the system.

AQS-200 Enterprise Architect: The architect regularly reviews national applications that are documented in the AQS-200 architecture to ensure currency of the application architecture as represented in the EA.

AQS-200 IT Training Program Manager: Changes to applications after they become operational should be coordinated with the IT Training PM to ensure consistency and accuracy of on-going training curriculum.

10.4. DELIVERABLES, RESPONSIBILITIES AND ACTION10.4.1. Periodic System Review ReportPeriodic reviews shall be held at predetermined milestones usually at least once a year. The performance measure should be reviewed along with the health of the system. Performance measures should be measured against the base measures. Ad hoc reviews should be called when deemed necessary by either party.

10.4.2. User Satisfaction ReviewWhen, how often, how are the objectives of the program being met, should objective be changed, what are results? The survey can be used as a tool to determine the need to proceed with a Process Improvement Review Board meeting or initiate a proposal for a new system.

10.5. ISSUES FOR CONSIDERATION10.5.1. DocumentationIt cannot be stressed enough, that proper documentation for the duties performed by each individual responsible for system maintenance and operation should be up-to-date. For smooth day-to-day operations of any system, as well as disaster recovery, each individual’s role, duties and responsibilities should be outlined in detail. A systems administrator’s journal or log of changes performed to the system software or hardware is invaluable in times of emergencies. Operations manuals, journals or logs should be readily accessible by maintenance personnel.

10.5.2. Enterprise Architecture during Operations & MaintenanceGenerally, the architecture should be stabilized for the specific program by this time. Any architectural changes planned and/or implemented during this phase should be reported to the AQS-200 enterprise architect to ensure continued alignment with the AS-IS and TO-BE architecture of AQS-200’ environment.

10.5.3. Changes to the SystemBoundary Documents should be reviewed and updated as needed, other documents as needed should be updated and on-going user training should be addressed.



QPM #

AQS 200-001-WI

Revision

1


Any major change to the system’s architecture, functionality, interfaces, or design will trigger the need for a new SCAP and review of the Enterprise Architecture and the system’s associated training documents & curriculum. This will involve analyzing the changes, and updating the existing SCAP, EA, and training documentation to ensure that it continues to accurately reflect the system’s security posture, architecture, and training documentation.

10.5.4. Distinguishing New Development from MaintenanceChanges to the system should meet the following criteria in order for the change or modification request to be categorized as Maintenance; otherwise it should be considered as New Development:

Estimated cost of modification are below maintenance costs Proposed changes can be implemented within 1 system year Impact to system is minimal or necessary for accuracy of system output

10.6. REVIEW ACTIVITYReview activities occur several times throughout this phase. Each time the system is reviewed, one of three of the following decisions will be made:

The system will continue in operation, with or without modifications. The system will not be accepted and is returned to the System Proponent for

corrections or modifications. The system will be terminated and its functions and data transferred to other

systems.

The Periodic System Review (conducted at least annually) shall be conducted in this phase. The Periodic System Review shall be performed to evaluate system performance, user satisfaction with the system, adaptability to changing business needs, and new technologies that might improve the system. This review is diagnostic in nature and can lead to development or maintenance activities. Any major system modifications needed after the system has been implemented will follow the life cycle process from planning through implementation. A project management plan, including a feasibility study, will identify modifications to existing system documentation (change pages) rather than new system documentation (for example, a functional requirements document, a system design document, etc.). The appropriate reviews and testing will be conducted, based on the scope of the modification.



QPM #

AQS 200-001-WI

Revision

1


11 PHASE 9: DISPOSITION PHASE

11.1. OBJECTIVEThe Disposal Phase will be implemented to eliminate a large part of a system or as in most cases, close down a system and end the life cycle process. The system in this phase has been declared surplus and/or obsolete and will be scheduled for shut-down. The emphasis of this phase will be to ensure that data, procedures, and documentation are packaged and archived in an orderly fashion, making it possible to reinstall and bring the system back to an operational status, if necessary, and to retain all data records in accordance with AVS policies regarding retention of electronic records. The Disposition phase represents the end of the systems life cycle. A Disposition Plan (Section 48) shall be prepared to address all facets of archiving, transferring, and disposing of the system and data. Particular emphasis shall be given to proper preservation of the data processed by the system do that it is effectively migrated to another system or archived in accordance with applicable records management regulations and policies for potential future access. The system disposition activities preserve information not only about the current production system but also about the evolution of the system through its life cycle.

11.2. TASKS AND ACTIVITIESThe objectives for all tasks identified in this phase are to retire the system, software, hardware and data. The tasks and activities actually performed are dependent on the nature of the project. The disposition activities are performed at the end of the systems life cycle. The disposition activities ensure the orderly termination of the system and preserve vital information about the system so that some or all of it may be reactivated in the future if necessary. Particular emphasis shall be given to proper preservation of the data processed by the system, so that the data are effectively migrated to another system or disposed of in accordance with applicable records management and program area regulations and policies for potential future access. These activities may be expanded, combined or deleted, depending on the size of the system.

11.2.1. Prepare Disposition PlanThe Disposition Plan must be developed and implemented. The Disposition Plan will identify how the termination of the system/data will be conducted, and when, as well as the system termination date, software components to be preserved, data to be preserved, disposition of remaining equipment, and archiving of life-cycle products. There may be security requirements that apply to disposal of IT assets, such as degaussing media, so the Disposition Plan should address these. Disposition should also be coordinated with the AQS-200 Enterprise Architect to ensure the transition from active to sunset is properly conveyed in the enterprise architecture.

11.2.2. Archive or Transfer DataThe data from the old system will have to be implemented into the new system or if it is obsolete, archived.



QPM #

AQS 200-001-WI

Revision

1


11.2.3. Archive or Transfer Software ComponentsSimilar to the data that is archived or transferred, the software components will need to be transferred to the new system, or if that is not feasible, disposed of.

11.2.4. Archive Life Cycle DeliverablesA lot of documentation went into developing the application or system. This documentation needs to be archived, where it can be referenced if needed at a later date.

11.2.5. End the System in an Orderly MannerFollow the plan in the Disposition Plan for the orderly breakdown of the system, its components and the data within.

11.2.6. Dispose of EquipmentIf the equipment can be used elsewhere in the organization, recycle. If it is obsolete, notify the property management office to excess all hardware components. Ensure that security requirements are complied with, so that sensitive data will not be exposed once the equipment is disposed of.

11.2.7. Prepare Post-Termination Review ReportThis review will be performed at the end of the Disposition Phase and again within 6 months after disposition of the system.

11.3. ROLES AND RESPONSIBILITIESManager of Application: Authors the Deposition Plan and ensures that all aspects of the Disposition Plan are followed. The Disposition Plan should outline all roles and responsibilities for all actions related to the close down and archive of the system. The Manager prepares the Post-termination Review Report.

Project Manager: Works with the Manager of the Application to ensure that the Deposition Plan is followed. The Project Manager is the one who finalizes the Disposition process.

Technical Support or Vendor Support: The Disposition Plan may call for the Technical Support Personnel to send system related hardware to a warehouse or may reassign equipment to a new or replacement system. Technical Support personnel may be asked to ghost hard drives due to the sensitive nature of data. Technical Support Personnel or Operators may perform the cutoff of users’ access per instructions from the Security Manager. Technical Support personnel may assist with the archive of the Information Systems data. They would perform the actual archive process.

Data Administrator: The Disposition Plan may direct that only certain systems data be archived. The Data Administrator would identify the data and assist technical personnel with the actual archive process. The Data Administrator may be involved with identifying data which due to its sensitive nature must be destroyed. They would also be involved with identifying and migrating data to a new or replacement system.

Users Services (Training & Help Desk): User Services includes the training, telecommunications, and the help desk. The training component coordinates and schedules the



QPM #

AQS 200-001-WI

Revision

1


development and delivery of all ADP training and facilitates the development of systems training methods and materials. It advises and assists development teams in the preparation of user training and monitors user feedback on training adequacy. In this phase, the Users Services may assist with the retraining of users to facilitate the transfer to a new or replacement system.

Operations (turn off systems, start tasks, backup etc) interfaces with the computer facility that will host the system being developed. This group also schedules, executes, and verifies production job streams; distributes specified outputs; handles other production control activities; and maintains and monitors centralized mainframe database management system software and runtime environments. It also acquires, maintains, customizes and tunes operating system software, assesses the affect of new or changed systems upon the operational environments, manages system software capacities, and advises on or arranges accommodation of new application systems. In this phase, the Operators would assist Technical Support, Security Manager and Data Administrators with the actual archive process.

Program Manager / Analysts: Program Managers need to plan and schedule a smooth shut-down. They also should be sure that all documentation is accumulated to be archived with the system.

Customers (Users Group): The customers (user group) ensure the active participation of users at all levels in the definition, design, and development of a re-engineered automation system for the capture, processing, tracking, and reporting. The purpose of the user group is to provide a forum for end users' input, coordination, and validation of their automation requirements. The group will provide a consistent work force responsible for initiating and resolving issues relating to system development efforts and expeditiously resolve issues relating to the identification and documentation of requirements.

Security Staff: The security staff will need to make sure that all access authority has been eliminated for the users. Any users that only use the application should be removed from the system while others that use other applications as well as this one may still need access to the overall system, but not the application being shut-down. If there is another application that is taking the place of this application, the security staff for each application should coordinate appropriately so that security issues are not introduced by the transition..

AQS-200 Enterprise Architect: The AQS-200 EA will ensure regular review of national applications that are documented in the AQS-200 Enterprise Architecture to ensure currency of the application architecture as represented in the EA. For systems that are sunset, the enterprise architecture will be updated to reflect the appropriate transition information.

11.4. DELIVEABLES, RESPONSIBILITIES AND ACTIONThe following deliverables are initiated and finalized during the Disposition Phase

11.4.1. Disposition PlanThe objectives of the plan are to end the operation of the system in a planned, orderly manner and to ensure that system components and data are properly archived or incorporated into other systems. This will include removing the active support by the operations and maintenance organizations. The users will need to play an active role in the transition. All concerned groups will need to be kept informed of the progress and target dates. The decision to proceed with



QPM #

AQS 200-001-WI

Revision

1


Disposition will be based on recommendations and approvals from a Periodic Review or based on a date (or time period) specified in the System Boundary Document (SBD).

This plan will include a statement of why the application is no longer supported, a description of replacement / upgrade, list of tasks/activities (transition plan) with estimated dates of completion and the notification strategy. Additionally, it will include the responsibilities for future residual support issues such as identifying media alternatives if technology changes; new software product transition plans and alternative support issues (once the application is removed); parallel operations of retiring and the new software product; archiving of the software product, associated documentation, movement of logs, code; and accessibility of archive, data protection identification, and audit applicability.

11.4.2. Post-Termination Review ReportThe Post-Termination Review Report is a report at the end of the process that details the findings of the Disposition Phase review.

11.4.3. Archived SystemThe packaged set of data and documentation containing the archived application is retained.

11.5. ISSUES FOR CONSIDERATIONUpdate of Security plans for archiving and the contingency plans to reestablish the system should be in place.

All documentation about the application, system logs and configuration will be archived along with the data and a copy of the Disposition Plan.

11.5.1. Enterprise Architecture during DispositionThe AQS-200 Enterprise Architecture must be updated to reflect the disposition of the application. The architecture should already be updated to reflect the information about the replacement application, if any.

11.6. REVIEW ACTIVITYThe Post-Termination Review shall be performed after the end of this final phase. This phase-end review shall be conducted within 6 months after disposition of the system. The Post-Termination Review Report documents the lessons learned from the shutdown and archiving of the terminated system.



QPM #

AQS 200-001-WI

Revision

1


12 ALTERNATIVE SDLC WORK PATTERNS

12.1. OBJECTIVEAn important objective of an SDLC methodology is to provide flexibility that allows tailoring of the methodology to suit the characteristics of a particular system development effort. One methodology does not fit all sizes and types of system development efforts. For instance, it is not reasonable to expect a very small system development project to produce 38 deliverables and a different approach might be needed for a high-risk system development project that has very uncertain functional and technical requirements at the beginning of development. Therefore, the AQS-200 SDLC methodology provides for a full sequential SDLC work pattern and for alternative SDLC work patterns. It also provides a work pattern to accommodate the acquisition and implementation of a commercial-off-the-shelf (COTS) product.

12.1.1. Standard SDLC Methodology (Full Sequential Work Pattern)The standard SDLC methodology, as represented in Section 3, Phase 1: System Concept Development Phase through Section 11, Phase 9: Disposition Phase, is termed a "full sequential work pattern." This full sequential work pattern creates the maximum number of deliverables (see Figure 3-4: Planning Documents, in Section 2, Key Supporting Processes).

During the Planning Phase, the Project Manager, in conjunction with the System Proponent, evaluates the documentation of the system concept, as contained in supporting documentation, and determines if the standard AQS-200 SDLC methodology should be used or if an alternative work pattern should be selected instead. The selection of work patterns is based on the selection criteria and the judgment of the involved management. In general, the full sequential work pattern is used if the development type is new or a large modification; if the system development size is large; if the associated mission is critical; if the system development risks are normal or high; and if complexity of the system development effort is normal or high.

In the full sequential work pattern, a project is divided into phases; the phases are conducted sequentially, and the initiation of each phase depends on a decision to continue that is made during a formal review near the end of the immediately preceding phase. This work pattern reflects a desire to follow a very conservative approach to project management.

A complete set of system development activities, tasks, and deliverables to be considered for inclusion in this full sequential work pattern is presented in Sections 3 through 11.

12.2. ALTERNATIVE WORK PATTERNSAlternative work patterns provide flexibility for the AQS-200 SDLC methodology. An alternative work pattern permits a project planner to tailor a project management plan to meet the specific needs of the project and still conform to SDLC standards. Alternative work patterns provide the opportunity for methods specialists to predefine the permitted tailoring, to ensure that a project planner's customization does not overlook necessary activities or include unneeded ones. The alternative work patterns provided are as follows:

Reduced effort work pattern Rapid application development (RAD) work pattern



QPM #

AQS 200-001-WI

Revision

1


Pilot development work pattern Managed evolutionary development (MED) work pattern O&M small-effort enhancement work pattern O&M project work pattern Commercial-off-the-shelf (COTS) acquisition

The following are operational definitions for terms associated with these types of projects:

Proof of Concept: A project that defines what will be proven and determines both the criteria and methods for the proof of concept. Once the proof of concept is demonstrated, a prototype project may be initiated.

Prototype: An ensemble that is suitable for the evaluation of design, performance, and production potential and is not required to exhibit all the properties of the final system. Prototypes are installed in a laboratory setting and are not installed in the field, nor are they available for operational use. They are maintained only long enough to establish technical feasibility.

Proof of Technical Feasibility: The result of a successful prototype.

Pilot: A system installed in the field to demonstrate that the systems concept is feasible in an operational environment. The pilot system installed has a predetermined subset of functions and is used by a bounded subset of the user population. Its features may not all function smoothly. The goal of the pilot is to provide feedback that will be used to refine the final version of the product. The pilot will be fielded for a preset, limited period of time only to permit pilot systems to be evaluated for operational feasibility.

Proof of Operational Feasibility: The result of a successful pilot.

Production: A fully documented system, built according to the SDLC, fully tested, with full functionality, accompanied by training and training materials, and with no restrictions on its distribution or duration of use.

12.3. ALTERNATIVE WORK PATTERN SELECTIONDuring the Planning Phase, the Project Manager, along with the System Proponent, evaluates the system concept definition documentation and uses the criteria for selecting either the full sequential work pattern or an alternative work pattern.

This section shows the criteria for selecting an alternative work pattern. (Note: Criteria for selection may not be mutually exclusive - for example, complexity and size because size may be a factor of complexity.)

Determine the type of system development:

New development Modification or enhancement of existing system Prototype system Procurement of a COTS system O&M small scale enhancement



QPM #

AQS 200-001-WI

Revision

1


O&M project

Determine the cost of the system development project using the guidelines below:

Class 1: Very large projects with estimated development or life cycle costs of more than $20 million

Class 2: Large projects with estimated development or life cycle costs of between $10 million and $20 million

Class 3: Mid-size projects with estimated development or life cycle costs of between $2.5 million and $10 million

Class 4: Small projects with estimated development or life cycle costs of between $500,000 and $2.5 million

Class 5: O&M enhancement with estimated life cycle costs of less than $500,000.

Determine mission-criticality of system development:

Critical (C3) Mission Critical (C2) Non-Mission Critical (C1)

Determine the risk of inability to achieve the project objectives. The project objectives should be ranked using the following values;

High (D3)

Medium (D2)

Low (D1),

The criteria for ranking each of the project objectives are as follows;

Risk due to high uncertainty associated with the system's requirements, the technology that the system will employ, or the way that the system will affect AVS’ business process

Risk due to high visibility due to public or political attention or requirements Risk due to highly compressed development time (low turnaround time) because

of an emergency or legal, business or political requirements

Determine the complexity of the system development effort from highest (E3) to lowest (E1). The project objectives should be ranked using the following values;

Highest (E3)

Medium (E2)

Low (E1)

The criteria for ranking the complexity of the system development effort are as follows;

The project affects many organizations or functional areas within AVS, thus adding a level of difficulty regarding the definition of requirements.



QPM #

AQS 200-001-WI

Revision

1


The project results from business process reengineering, dramatically altering the use of information technology.

The project requires new or rapidly advancing technology. The project requires a long time for development.

Use Figure 13-12: Alternative Work Pattern Selection, to select the work pattern appropriate for your project.

FIGURE 13-12: ALTERNATIVE WORK PATTERN SELECTION

Selection Criteria Work PatternA. Type of Development = anyB. Cost = Class 4C. Mission Criticality = allD. Risk = D2 to D1E. Complexity = E2 or E1

Reduced Effort (small application) Work Pattern

A. Type of Development = 1, 2, 3B. Cost = Class 3 or 4C. Mission Criticality = allD. Risk = D2 to D1E. Complexity = E2 or E1

RAD Work Pattern

A. Type of Development = 1B. Cost = Class 2 and 3C. Mission Criticality = C2 to C3D. Risk = D3E. Complexity = high

Pilot Development Work Pattern

A. Type of Development = 1B. Cost = Class 1 and 2C. Mission Criticality = C3 or C2D. Risk = D3E. Complexity = E3

MED Work Pattern

A. Type of Development = 1B. Cost = Class 1 and 2C. Mission Criticality = C3 to C2D. Risk = D3E. Complexity = E3 to E2

Full Sequential Work Pattern



QPM #

AQS 200-001-WI

Revision

1


Selection Criteria Work PatternA. Type of Development = 5B. Cost = Class 5C. Mission Criticality = AnyD. Risk = AnyE. Complexity = Any

O&M Small Scale Enhancement

A. Type of Development = 6B. Cost = Class 2 to 4C. Mission Criticality = AnyD. Risk = AnyE. Complexity = Any

O&M Project

A. Type of Development = 4B. Cost = Class 3 or 4C. Mission Criticality = AnyD. Risk = AnyE. Complexity = Any

COTS Acquisition

12.4. WORK PATTERN DESCRIPTIONS AND EXHIBITSThe subsequent sections provide descriptions for each alternative work pattern, including tasks and activities, required deliverables, and reviews for each relevant phase.

Deliverables for alternative work patterns are often created, revised, and finalized across multiple life cycle phases, as with the full sequential work pattern.

12.4.1. Reduced Effort Work PatternA Reduced Effort work pattern combines some phases, eliminates some of the deliverables otherwise required, and combines some of the reviews to reduce project formality in those situations where a conservative approach is not necessary. This is illustrated in Figure 13-13: Reduced Effort Work Pattern. Figure 13-14: Reduced Effort Work Pattern Summary, shows, by phase, the tasks, the deliverables required, and the types of reviews required. Chapters 4 through 12 provide identification of the numbered tasks cited in the exhibit.



QPM #

AQS 200-001-WI

Revision

1


FIGURE 13-13: REDUCED EFFORT WORK PATTERN

FIGURE 13-14: REDUCED EFFORT WORK PATTERN SUMMARY

Phase Tasks Deliverables (Work Products) Formal Reviews

System Concept Development

Define/document business need

Develop a recommendation

Present findings to executive management

Conduct ADP position sensitivity analysis

Cost-Benefit AnalysisRisk Management

PlanSystem Boundary

DocumentFeasibility Study

Cost-Benefit AnalysisRisk Management

PlanFeasibility StudySystem Boundary

DocumentPhase-End

Planning and Requirements Analysis

Review security requirements

Plan CMAnalyze and

document requirements

Develop test criteria and plans

Establish QA mechanisms

Acquisition PlanCM PlanProject Management

PlanConcept of

OperationsFRDQA PlanTest & Evaluation

Master Plan

Acquisition PlanCM PlanProject Management

PlanConcept of

OperationsFunctional

RequirementsQA PlanTest & Evaluation



QPM #

AQS 200-001-WI

Revision

1



Establish project and system security

System Security PlanPrivacy Act NoticeICDSystems Engineering

Management PlanV&V PlanRecords Disposition

Schedule

Master PlanSystem Security PlanSystem InterfacesV&V PlanSystems Engineering

Management PlanPhase-End

Design and Development

Design the applicationDesign business

processesDesign

conversion/migration/transition strategies

Continue procurement activities

Continue CM and change control

Develop security operating procedures

Develop the application

Develop business processes

Institute internal management controls

System Design Document

Implementation PlanSoftware

Development Document

System SoftwareTest files/dataContingency PlanOperations ManualConversion PlanSecurity Risk

AssessmentMaintenance ManualTraining PlanUser ManualIntegration DocumentTest Analysis Report

Final System DesignImplementation PlanSecurity Risk

AssessmentContingency PlanConversion PlanMaintenance ManualTraining PlanUser ManualIntegration DocumentSoftware peer reviewsTest ReadinessPhase-End

Integration &Test and Implementation

Conduct subsystem integration testing

Conduct system testing

Conduct user acceptance testing

Conduct test analysis review

Computer user and operator training

Install system in production

Test Problem ReportsTest Analysis

Approval Determination

IT Systems Security Certification & Accreditation

Delivered systemChange

Implementation Notice

Version Description

Version Description Document

Post-implementation Review

Phase-End



QPM #

AQS 200-001-WI

Revision

1



environmentConvert data to

production environment

Confirm that the system is ready for operation

Continue configuration status accounting and change control

Certify system security and readiness features

Complete acquisitionsPerform operation

reviewsObtain formal

acceptance of the installed system from the user

Document (initial release)

Post-implementation Review Report

Operations & Maintenance

All in Chapter 11Note: System begins

O&M Project Work Pattern

Periodic System Review Report

User Satisfaction Review

Note: See O&M Project

Periodic System Review


Note: See O&M Project

Disposition All in Chapter 12 Disposition PlanPost-termination

Review Report

Post-disposition

12.4.2. Rapid Application Development Work PatternIn the RAD work pattern, the System Concept Development and Planning Phases are conducted according to the full sequential work pattern. The Requirements Analysis and Design Phases are iteratively conducted, using prototyping tools to rough out and incrementally improve the understanding of requirements through a series of design prototypes. The functional requirements document and the system design document are started at the beginning of this activity but are not completed until the end of the Design Phase; these documents use, as much as is possible, the outputs of the prototyping tool to create this documentation. In the process, an initial set of requirements is used to create an initial version of the application, giving users visibility into the look, feel, and navigation capabilities of the application. User evaluation and feedback provide revisions to the statements of requirements, and the process is



QPM #

AQS 200-001-WI

Revision

1


repeated - always involving the user. Typically, three cycle iterations will result in a completely understood set of requirements, but the iteration process can continue until successive differences in requirements are so small as to not be noticeable.

Following the completion of design prototyping, a full sequential work pattern is again engaged to accomplish the Development, Integration and Test, and Implementation Phases. The only deviation is the possibility of using some of the generated code from the design prototype to start the Development Process. This is illustrated in Figure 13-15: RAD Work Pattern. Figure 13-16: RAD Work Pattern Summary, shows, by phase, the tasks, the deliverables required, and the types of reviews required.

FIGURE 13-15: RAD WORK PATTERN

FIGURE 13-16: RAD WORK PATTERN SUMMARY




QPM #

AQS 200-001-WI

Revision

1


System Concept Development All in Chapter 4

Cost-Benefit Analysis

Feasibility Study

Risk Management Plan

System Boundary Document


Feasibility Study



Phase-End

Planning All in Chapter 5

Acquisition Plan

CM Plan

QA Plan

Project Management Plan

V&V

CONOPS

System Security Plan

Systems Engineering Management Plan

Acquisition Plan

CM Plan

QA Plan


V&V Plan

CONOPS



Phase-End



QPM #

AQS 200-001-WI

Revision

1


Requirements Analysis and Design

The following combined phase tasks are iterative:

Assess the current situation

Analyze and document requirements Establish the application environment

Design the application

-End of iterative tasks-

The following combined phase tasks are not iterative:

Develop test criteria

Establish project and system security

Revise Planning Phase documents

Design business processes

Design conversion/migration/ transition strategies

Develop security operating procedures

FRD

System Design Document (Based on Design Prototype)

Interface Control Document

Test & Evaluation Master Plan

Security Risk Assessment

Implementation Plan

Privacy Act Notice

Records Disposition Schedule

Contingency Plan

Conversion Plan

Maintenance Manual

Operations Manual or Systems Administration Manual (client/server)

Training Plan

User Manual

Note: FRD and SDD may be published as one deliverable

Functional Requirements

Design (Based on Design Prototype)

System Interfaces



Implementation Plan

Design Phase-End

Contingency Plan

Conversion Plan

Maintenance Manual

Operations Manual or Systems Administration Manual (client/server)

Training Plan

User Manual

Note: Requirements and Design reviews may be combined.

Development All in Chapter 8

Software Development Document

Integration Document

System software

Test files/data

Test Analysis Report

Software peer reviews

Test Readiness

Phase-end



QPM #

AQS 200-001-WI

Revision

1


Integration & Test All in Chapter 9

Test Problem Reports

Test Analysis Approval Determination


Phase-End

Implementation All in Chapter 10

Delivered system

Post-implementation Review Report

Change implementation Notice

Version Description Document (initial release)

Version Description Document


Phase-End


All in Chapter 11

Note: System begins O&M Project Work Pattern

Periodic System Review Report


Periodic System Review


Disposition All in Chapter 12Disposition Plan

Post-termination Review Report

Post-Disposition

12.4.3. Pilot Development Work PatternIn a pilot development work pattern, either a full sequential work pattern or a RAD work pattern is used to go from System Concept Development through the Development Phase. Decisions regarding full deployment of the application are held until after field trials and evaluations have proven the concept because of the risk involved in the complexity, visibility, and uncertainty of the project. The field trials and evaluations accomplish portions of user acceptance testing and implementation; after they are complete, possibly requiring 1 or more years, the remainder of implementation is completed. This means that migration to the Operations and Maintenance Phase is possibly deferred for more than a year. This is illustrated in Figure 13-17: Pilot Development Work Pattern. Figure 13-18: Pilot Development Work Pattern Summary, shows, by phase, the tasks, the deliverables required, and the types of reviews required.



QPM #

AQS 200-001-WI

Revision

1


FIGURE 13-17: PILOT DEVELOPMENT WORK PATTERN

FIGURE 13-18: PILOT DEVELOPMENT WORK PATTERN SUMMARY


System Concept Development All in Chapter 4


Feasibility Study




Feasibility Study



Phase-End



QPM #

AQS 200-001-WI

Revision

1



Planning All in Chapter 5

Acquisition Plan

CM Plan

QA Plan


CONOPS


V&V Plan


Acquisition Plan

CM Plan

QA Plan



CONOPS

V&V Plan

Systems Engineering Management plan

Phase-End

Requirements Analysis

All in Chapter 6

Note: The Pilot Development Work Pattern may also follow the Rapid Application Development Work Pattern for the Requirements Analysis and Design Phases.

FRD


ICD

Privacy Act Notice

Records Disposition Schedule

Functional Requirements


System Interfaces

Phase-End

Design

All in Chapter 7

Note: The Pilot Development Work Pattern may also follow the Rapid Application Development Work Pattern for the Requirements Analysis and Design Phases.



Implementation Plan

Conversion Plan

Maintenance Manual

Operations Manual or Systems Administration Manual (Client/server)

Training Plan

User Manual

Contingency Plan

Design

Implementation Plan

Conversion Plan

Maintenance Manual

Operations Manual or Systems Administration Manual (Client/server)

Training Plan

User Manual

Contingency Plan

Final System Design

(Phase-End)



QPM #

AQS 200-001-WI

Revision

1





Integration Document

System software

Test Analysis Report

Test files/data


Test Readiness

Phase-End

Integration and Test All in Chapter 9

Test Problem Reports



Field Test and Evaluation

Implementation

Deferred until Field Test and Evaluation proves system concept, then all in Chapter 10

Deferred until Field Test and Evaluation proves system concept, then Delivered system

Change Implementation Notice

Post-implementation Review Report Version Description Document


Phase-End


Deferred until Field Test and Evaluation proves system concept, then all in Chapter 11

Deferred until Field Test and Evaluation proves system concept, then Periodic System Review Report



Periodic System Review (to evaluate concept)

Disposition All in Chapter 12Disposition Plan

Post-termination Review Report

Post-disposition

12.4.4. Managed Evolutionary Development Work PatternThe MED approach is particularly suited to situations where existing business processes will be altered considerably and where the full set of detailed functional requirements cannot be reliably



QPM #

AQS 200-001-WI

Revision

1


defined early in the development life cycle. The MED discipline supports iterative definition, development, and deployment of subsystems by defining system-level functional and data requirements and a modular system architecture, which allows for subsequent refinement, development, and deployment of subsystems that can evolve to meet future business needs. Frequently, a particular release level containing partial, but not complete, functionality is referred to as a "build". During the Planning and Requirements Analysis Phases, an entire series of successive builds is planned, each of which gets designed, developed, tested, and implemented.

This is illustrated in Figure 13-19: MED Work Pattern. Figure 13-20: MED Work Pattern Summary, shows, by phase, the tasks, the deliverables required, and the types of reviews required.

FIGURE 13-19: MED WORK PATTERN

MED Incremental and Evolutionary Strategies: The MED-based development process combines an evolutionary development strategy with incremental delivery. System development using MED proceeds by defining a bounded vision of a future system, and then iteratively refining the reengineered business processes, information system requirements, and technical architecture. The incremental delivery strategy within MED is used to encapsulate part of the overall system as a subsystem to be built and deployed. Subsystems are constructed when there is sufficient confidence that they will provide a cohesive, user-validated set of business functionality. As



QPM #

AQS 200-001-WI

Revision

1


usage experience is obtained, lessons learned are fed back into each subsystem by improving each in subsequent versions of the system.

MED Program Management: The Planning Phase is where the Project Manager, with approval of the System Proponent, determines that the functional requirements will best be fulfilled by assigning them to distinct, but functionally related subsystems. The Requirements Analysis Phase will be split into a Systems Requirements Analysis Phase to define overall system requirements and architecture and a Subsystem Requirements Analysis Phase for detailed definition of each subsystem. At the completion of the Requirements Analysis Phase, each subsystem begins its own branch of the life cycle to define a target subsystem architecture, business process, and requirements.

Risk Management within the Context of MED: The order in which a MED-based work pattern proceeds is heavily influenced by risk. MED is designed to focus explicitly on the development decisions around risk that is derived from uncertainty about the target system in the areas of business process, system requirements, technical architecture, cost, and schedule. This risk management strategy addresses two fundamental time-related risks of uncertainty and dependence. Uncertainty is reduced by acting on gathered information, such as from prototypes, simulations, studies, or models; dependence is eliminated by structuring parts of the system to be independently deployed as subsystems. To accomplish this, the Project Manager must define the target system. This consists of determining the system boundaries, specifying the target characteristics, assessing system risks and defining and executing risk mitigation activities; and developing subsystems, which is done as a project within the overall program. Projects are initiated once system-level risk is reduced to an acceptable level as documented in the risk management plan.

Reviews and Approvals: When using the MED Work Pattern, there is an explicit milestone for the system-level requirements and a milestone for each subsystem requirement.

FIGURE 13-20: MED WORK PATTERN SUMMARY


System Concept Development

All in Chapter 4Determine System Boundary

Cost-Benefit AnalysisFeasibility StudyRisk Management PlanSystem Boundary Document

Cost-Benefit AnalysisFeasibility StudyRisk Management PlanSystem Boundary DocumentPhase-End



QPM #

AQS 200-001-WI

Revision

1



Planning

All in Chapter 5 plus:Divide system into independent subsystems Plan incremental releases (builds)

Acquisition PlanCM PlanQA PlanProject Management PlanCONOPSSystems Security PlanV&V PlanSystem Engineering Management Plan

Acquisition PlanCM PlanQA PlanProject Management PlanCONOPSSystems Security PlanV&V PlanSystems Engineering Management PlanPhase-End

Requirements Analysis

All in Chapter 6Note: All Tasks, Deliverables, and Reviews from Requirements Analysis Phase through Operations & Maintenance Phase are done for each build defined during the Planning Phase

FRDTest & Evaluation Master PlanICDRecords Disposition SchedulePrivacy Act Notice

Functional RequirementsTest & Evaluation Master PlanSystem InterfacesPhase-End

Design All in Chapter 7

Systems Design DocumentImplementation PlanConversion PlanMaintenance ManualOperations Manual or Systems Administration Manual (client/server)Training PlanUser ManualContingency PlanSecurity Risk Assessment

DesignImplementation PlanConversion PlanMaintenance ManualOperations Manual or Systems Administration Manual (client/server)Training PlanUser ManualContingency PlanSecurity Risk AssessmentFinal System Design(Phase-End)



QPM #

AQS 200-001-WI

Revision

1




Software Development DocumentIntegration DocumentSystem softwareTest Analysis ReportTest files/data

Software peer reviewsTest ReadinessPhase-End

Integration and Test All in Chapter 9

Test Problem Reports and Test Analysis approval DeterminationIT Systems Security Certification & Accreditation

Phase-End

Implementation All in Chapter 10

Version Description Document (per build, up to complete system)Change Implementation NoticePost-implementation Review Report Delivered system

Post-implementation ReviewVersion Description DocumentPhase-End


All in Chapter 11Note: System begins O&M Project Work Pattern

Periodic System Review ReportUser Satisfaction Review

Periodic System ReviewUser Satisfaction Review

Disposition All in Chapter 12Disposition PlanPost-termination Review Report

Post-disposition

Acknowledgment for the MED Methodology. The U.S. Patent and Trademark Office developed and documented the MED methodology. A full description of MED may be found in: the Managed Evolutionary Development Guidebook, Second Edition, June 1993. This is a document produced by the U.S. Patent and Trademark Office. For further information contact: The Office of the Assistant Commissioner for Information Systems, U.S. Patent and Trademark Office, 2121 Crystal Drive, Arlington, VA 22202, (Fax) 703-305-9369.

12.4.5. O&M Small-Scale Enhancement Work PatternThis work pattern is appropriate for small scale revisions to existing applications. Each O&M enhancement must be initiated by the Project Manager and must be tracked by an SCR.



QPM #

AQS 200-001-WI

Revision

1


Typically, multiple O&M enhancements will be bundled into a planned software release identified by a version number.

The intent is to limit the use of this work pattern to simple, small-scale changes that will require no more than 160 labor hours for Concept Development, Requirements Analysis, Design, Development, Integration & Testing, and Implementation, including any needed updates to product documentation and any required user training.

Figure 13-21: O&M Enhancement Work Pattern Summary shows, by phase, the tasks, deliverables, and types of reviews required.

FIGURE 13-21: O&M ENHANCEMENT WORK PATTERN SUMMARY

Phase Tasks Deliverables (Work Products) Reviews

Concept Development and Planning Phase

Evaluate SCR(s)Obtain approval to maintain an

existing application.Confirm total effort is less than

160 labor hours (otherwise, see O&M Project).

Determine appropriate module(s) in which to make changes.

Identify urgency and priorityDevelop a work schedule and

estimate of resource requirements.

Identify release and version number in which the change will be included.

Identify existing security and privacy requirements for the application needing revision.

Change Impact Assessment

Change DirectiveProject Management

Plan (Small-scale enhancement)

IRM review of SCR


Phase-End

Requirements Analysis and Design Phases

Identify applicable requirements; issue FRD addendum.

Design the required change.Identify needed revisions to

baseline documents.

Addendum to CONOPSAddendum to FRDAddendum to ICDMarked-up pages of

baseline documents requiring changes

CONOPS Requirements

System Interfaces

Updated Design (Phase-End)



QPM #

AQS 200-001-WI

Revision

1


Development and Integration & Test Phases

Develop changesMake changes to appropriate

documentation.Revise and unit test application

software.Conduct system and

regression testing for this change.

Updated Software Development Document

Updated system software

Updated test files/dataTest Analysis Report

with attached Test Problem Reports


Updated Integration Document


Test ReadinessPhase-End


Complete Change Implementation Notice

Deploy revised software and documentation

Conduct required training

Modified software and documentation


Phase-End

12.4.6. O&M Project Work PatternThis work pattern is appropriate for O&M Maintenance for existing applications. Each O&M project must be specifically organized and staffed for the purpose of conducting corrective, adaptive, or perfective maintenance on installed applications, including conversions needed to support upgrades and/or changes to the hardware and software operating environment. User help desk support and other small O&M enhancements may also be provided and delivered by the assigned project team. System revisions and conversions will be accomplished on an as-needed basis at a fixed level of support and within a corresponding fixed annual operating budget. The intent is to limit the use of this work pattern to ongoing support activities that typically do not fit within the definition of a systems development or enhancement project.

Figure 13-22: O&M Project Work Pattern Summary, shows, by activity, the task, deliverables, and types of reviews required.



QPM #

AQS 200-001-WI

Revision

1


FIGURE 13-22: O&M PROJECT WORK PATTERN SUMMARY

Phases Tasks Deliverables (Work Products) Reviews

Concept Development and Planning Phase

Evaluate SCR(s)Obtain approval to maintain an

existing application.Determine appropriate module(s)

in which to make changes.Identify urgency and priority.Develop a work schedule and

estimate of resource requirements.

Identify release and version number in which the change will be included.

Identify existing security and privacy requirements for the application needing revision.

Change Impact Assessment

Change DirectiveProject Management

Plan (based on type of maintenance)

Change Control Board review of SCR


Phase-End

Requirements Analysis and Design Phases

Identify applicable requirements; issue FRD addendum if SCR(s) add or modify functional or performance requirements.

Design the required change.Identify needed revisions to

baseline documents.

Addendum to CONOPS (Enhancement only)

Addendum to FRD (Enhancement only)

Addendum to ICDMarked-up pages of

baseline documents requiring changes

CONOPS (enhancement only)

Requirements (enhancement only)

System InterfacesUpdated Design

(Phase-End)

Development and Integration & Test Phases

Develop changesMake changes to appropriate

documentation.Revise and unit test application

software.Conduct system and regression

testing for this change.

Updated Software Development Document

Updated system software

Updated test files/dataTest Analysis Report

with attached Test Problem Reports



Test ReadinessPhase-End


Complete Change Implementation Notice

Deploy revised software and documentation

Conduct required training

Modified software and documentation


Phase-End



QPM #

AQS 200-001-WI

Revision

1


Phases Tasks Deliverables (Work Products) Reviews

Conduct Adaptive Maintenance

(ongoing)

See O&M Enhancement work pattern.



Provide User Help Desk Support (ongoing)

Respond to user requests for help.

Maintain log of trouble tickets.None Periodic peer

review

12.4.7. Procurement of COTS ProductThis effort is designed for the purchase of Commercial-Off-the-Shelf (COTS) products to be used by AVS within the framework of existing or planning systems, see Figure 13-23. These COTS products may be used at a single site or they may be installed to operate across AVS or a significant portion of AVS. The table in Figure 13-12: Alternative Work Pattern Selection, indicates when this pattern is to be used.

FIGURE 13-23: COTS ACQUISITION WORK PATTERN SUMMARY


Concept Development and Planning Phases

Define business needCharter User Group

Feasibility StudyCost Benefit AnalysisRisk Management PlanUser Group CharterProject Management

PlanCM PlanQA PlanAcquisition PlanCONOPS

CONOPSSystem Concept

Development and

Planning Phase End

Requirements Analysis Phase

Identify functional requirements

Identify sensitivity of the system

Conduct security risk assessment

Develop plan for User Acceptance Testing

Determine Privacy Act implications

Continue acquisition activities

FRDSystem Security PlanSecurity Operating

Procedures (See Note)

Contingency Plan (See Note)


User Acceptance Test Plan

Privacy Act Notice

Requirements



QPM #

AQS 200-001-WI

Revision

1



Acquisition Phase (replaces Design and Development)

Perform Market SurveyEvaluate productsInitiate selection processDefine customization

requirementsPrepare Statement of WorkObtain AIS approvalInitiate purchase of selected

COTSDevelop User manualPrepare Training PlanDevelop Conversion PlanDevelop Implementation

Plan

Statement of WorkICDUser ManualTraining PlanConversion PlanImplementation PlanCOTS Product

Statement of WorkSystem InterfacesImplementation

Plan

Integration & Test Phase

Conduct Stress TestConduct Network Load TestConduct User Acceptance

TestConduct Security Test and

EvaluationReview test resultsInitiate problem resolutionsPrepare User Acceptance

Certificate

Test PlanTest Problem Report

Test Plan


Conduct trainingConvert dataImplement softwareCharter Change Control

Board

Change Control Board Charter

IT Systems Security Certification & Accreditation (See Note)

None

Operations & Maintenance Phase

Monitor systemIdentify problemsConduct Change Control

Board MeetingsNotify vendor of application

problemInitiate formal acquisition

request for any system customization requirement

None None



QPM #

AQS 200-001-WI

Revision

1



Disposition Phase All in Chapter 12Disposition PlanPost-Termination

Review Report

Disposition PlanPost-termination

(Phase-End)

NOTE: May not be required, depending on the nature of the COTS product. This document will be more likely required for systems made up entirely of COTS products that require significant customization and integration. The decision to develop this document should be made during this life cycle phase.

12.5. ADDITIONAL WORK PATTERNSProject teams should endeavor to follow the full sequential work pattern or one of the alternatives described above. However, from time to time, new project environments or system requirements into which these work patterns will not fit will evolve. In those cases, the Project Manager, working with the QA Manager, shall develop and document proposed new work patterns, submit them as updates to this guidance document, and use them as the basis of the project management plans.



QPM #

AQS 200-001-WI

Revision

1


13 SYSTEM BOUNDARY DOCUMENT

The following formats describe the System Boundary Document (SBD). Each format should be tailored for the project phase and the needs of the decision authority. As a general statement, the SBD should contain the minimum information needed to describe the project. Oversight tracking and reporting should be confined to the requirements listed in the approved SBD.

An SBD establishes the requirements for the project, guides the development and implementation, and expresses the commitment of agreement between the Program Management Office, the System Proponent Office, and the Executive Management Staff.

This document shall include the mission, requirements statement, business assumptions and constraints, system assumptions and constraints, program management assumptions and constraints, and program costs and scheduling.

13.1. FORMAT FOR SBD COVER MEMOFROM: SBD Preparer

TO: Project Leader

Agency Resource Owner(s)

External Resource Owner (if needed)

Agency Project Decision Authority

External Decision Authority (if needed)

SUBJECT: Project XXX Project SBD Approval Request

The attached SBD proposes the establishment (or continuation) of Project XXX as a recognized development project.

The signature of the project leader on the attached package establishes (or continues) the commitment of the project team to deliver the completed project within the cost, schedule, and performance shown in the attached baseline.

The signature of the resource owner(s) on the attached package establishes (or continues) the commitment of the resource owner to provide the resources identified in the attached package. The signature of the resource owner(s) also indicates to the decision authority that the identified resources can be made available as shown in the SBD.

The signature of the decision authority on the attached package establishes (or continues) the approval to execute the project in accordance with the attached SBD. Approval also establishes the waiver of specifically identified agency policies and procedures within the purview of the decision authority.

The Project Leader requests review and approval of the attached SBD for Project XXX.



QPM #

AQS 200-001-WI

Revision

1


13.2. THE REQUIREMENTS DOCUMENTThe Requirements Document (RD) establishes the operational framework and performance baseline for an automation program, and serves as an “agreement” with the customer on the requirements for that program. At the beginning of the Design Phase, the initial Requirements Document does not contain any requirement that would unduly restrict the search for solutions to mission need, and should not preclude leasing, commercial, or non-developmental solutions. As the design proceeds, the initial Requirements Document may be updated to reflect the candidate solutions, including both commercial of the shelf (COTS) and custom built. Before the Development Phase, the Requirements Document becomes the performance baseline of the program.

The Requirements Document must also record Congressional mandates, Executive Orders, and federal regulations that directly influence the requirement. Such specifications, standards, executive orders, and mandates shall be referenced in the appropriate section of the RD. Tailor them carefully so only applicable sections are applied. Use industry and international standards to the greatest possible extent.

The Requirements Document is the first major deliverable in the Design Phase. The responsible AQS-200 Program Manager, with appropriate participation and guidance from the customer community, will be responsible for its development. This participation may range from a single person to a user group with representatives from all affected organizations, but must be approved by the appropriate project decision authority.

13.3. TRACEABILITYThe requirements described in the Requirements Document shall be traceable from the Concept Paper and to design modules, test elements, and configuration items. As proposed changes to the requirements are approved, the RD should be updated, and plans and schedules adjusted accordingly to maintain this traceability.

To facilitate traceability, requirements should be numbered uniquely according to the following standard. The degree to which requirements will be numbered may vary among systems. However, ideally, each requirement that will be tested for final acceptance should have a unique number.

13.4. APPROVALA Requirements Document is approved by the following groups and individuals.

The Information System Users Group for the relevant application or function has first approval.

The AQS-200 Information Resource Manager has next approval. Finally, the document is sent to the appropriate project decision authority.

The project manager is responsible for obtaining the necessary approvals. During the project decision authority approval step a mutually agreed upon number of days to review and approve/disapprove will be determined. Lack of response from the project decision authority is construed as acceptance. All approvals are documented using cover letters with signoff lines.



QPM #

AQS 200-001-WI

Revision

1


13.5. USING THIS TEMPLATEThis template provides guidance for preparing the System Boundary Document. The definitions of the various chapters and sections are intended to guide preparation of the SBD. Not all sections of the SBD apply to every concept paper, particularly requirements that will be satisfied by human resource services.

In addition, some requirements may be unknown or unspecified initially. This information should be noted in the appropriate sections. Include an estimate of when the requirement will be specified and added to the requirements document. If these unknown requirements affect project scheduling and resource estimating, planning assumptions about these requirements will be documented in Appendix I.

13.6. AQS-200-CONTROLLED PARAMETERSCertain key parameters in the SBD are designated for control by the AVS office of the CIO (AQS-200). They are highlighted with bold, underlined text in the SBD. AQS-200 controls only those requirements that are critical to;

Achieving operational effectiveness and suitability, Meeting the needs of dependent elements of the AVS workforce, Accruing benefits ascribed to the candidate solution or acquisition program.

As a rule of thumb, AQS-200 controls no more than 5 - 10 requirements across all sections of the SBD.

13.7. CHANGE CONTROLAs the functional baseline of the Acquisition Program Baseline, the SBD is subject to the change procedures defined for AQS-200’ Software Development Life-Cycle. Therefore, modifications and addendums to it as a result of these change procedures are part of that baseline.

13.8. COSTThe resource estimate in the CONOPS addressed by this SBD is a placeholder in Service’s long-range planning of the in the AQS-200 Enterprise Architecture. It sets a rough boundary on the acceptable cost of solutions to the CONOPS.

13.9. SCHEDULEThe timeframe in the CONOPS specifying when the new capability must be operational defines the time available to develop and deploy a solution that is addressed by the requirements in this SBD. Expectations of what the final deliverable will be may be greatly modified by the time constraints imposed upon the project.

13.10. BENEFITSBenefit requirements at the beginning of Design Phase are the benefits defined in the CONOPS. Benefits must be measurable.



QPM #

AQS 200-001-WI

Revision

1


Chapter/Section Definition

Ch.1 Background

Identify the Concept Paper addressed by this Requirements Document and summarize the mission need. Describe briefly the deficiency in capability or technological opportunity, and how the proposed capability will satisfy the mission need. Identify AQS-200 Enterprise Architecture assets this capability is intended to satisfy or replace.

Ch.2 Operational Concept

2.1 OperationsDescribe how the capability will be used after it is deployed, and how it will support and affect primary customers (e.g., FAA engineers, FAA manufacturing inspectors, designees).

2.2 Maintenance

Describe the intended life of the capability from implementation through decommissioning. Include requirements for preventive maintenance, planned improvements, routine operations, and the degree of on-site and centralized maintenance.

2.3 Quantities and Location

Identify the total number of units or scope of services that will be needed to meet the need. Provide as much location information as possible, such as the number of workstations per Directorate or the location of servers.

2.4 Schedule Constraints

Identify the date by which the capability must be implemented at the first site. Identify the date by which all sites must achieve operational capability. Identify schedule constraints associated with any interfacing AQS-200 Enterprise elements required to achieve full operational capability.

Ch. 3 Technical PerformanceNo requirement should be entered into this section of the initial RD that is solution-specific or would unduly restrict the search for solutions to mission need.

3.1 Operational and Functional Requirements

Describe the capability needed in terms of user processes (not IT solutions or techniques) including user inputs, specific algorithms involved in computations, and desired outputs. Derived requirements that are discovered as necessary implications of requirements stated in the Concept Paper should also be documented. Where necessary, partitioning requirements may facilitate and focus the requirements analysis and subsequent design and testing. See Appendix A for examples.

3.2 Performance Requirements

Define performance requirements that are achievable, measurable, and specified in operational terms whenever practical. See Appendix B for examples.



QPM #

AQS 200-001-WI

Revision

1



3.3 Interfaces

Document external interface requirements for this capability. These interfaces include electronic data received or sent to other systems and subsystems, databases in other systems and subsystems that will be read or updated by this capability, and other systems and subsystems that will update data supporting this capability. Interfaces with non-AQS-200 Enterprise elements are included. Each interface should be described separately and with the interfacing entities designated by name, number, and version, as applicable.

Ch 4 Physical Integration

This chapter documents requirements for integrating a solution into the physical environment of AQS-200 and its customers. Initially, these requirements will be general, perhaps defined in terms of “not to exceed” values based on the existing environment. Factors such as physical space requirements and environmental concerns for equipment are described. Requirements to use the capability at customer sites such as a manufacturing floor should be included.

Ch 5 Human Integration

This chapter documents human/capability interface requirements for achieving optimum performance from a total capability perspective. These requirements are intended to ensure that products are designed and appropriate for the human workforce that will operate, maintain, and support them.

Ch 6 Security

6.1 User Security

Define security requirements for accessing the new capability. If different levels of access are anticipated, describe the type of users that will be given each level of access.

6.2 Database SecurityDefine security requirements relating to databases that will satisfy this capability. This may include special password protection and encryption.

6.3 Physical SecurityDefine security requirements relating to physical plant. This may include the storage of backup media, as well as server security.

Ch 7 Test and Evaluation

7.1 Critical Functions

Designate critical operational functions that must be included in User Acceptance Testing (UAT) when determining whether a new capability is operationally acceptable. These features typically relate to operational effectiveness which measures the degree to which a product satisfies mission requirements when used by representative personnel in the planned operational environment.



QPM #

AQS 200-001-WI

Revision

1



7.2 Environmental Factors

Define special environmental issues that must be tested during UAT to determine if the capability operates as required in critical environments. For example, a mobile computing device may be required to operate on a factory floor, or outdoors during a storm.

Ch 8 Implementation and Transition

This chapter defines requirements related to transition from the current capability to the new capability so as to not disrupt services. Implementation requirements typically encompass implementation planning, pre-installation checkout, installation and checkout, site integration, system shakedown, training, dual operations, and the removal/disposal of replaced systems, equipment, land, facilities, and other items. Also, define any directive or rule changes related to commissioning into the AQS-200 Enterprise.

Ch 9 Data

This chapter documents the characteristics of data used by this capability. Characteristics such as type, size, units of measure, domain, precision, security and privacy constraints, and sources should be included. The data should be grouped into logical entities, and the cardinal relationship of those entities should be specified. The focus of these data requirements is on the business rules and relationships, and not on the database design.

Ch 10 Standards This chapter lists the standards that are required for implementation of this capability.

Appendices

A. Minimum Performance Standards

Where applicable, specify a threshold value and an objective value for requirements. The threshold value is the minimum performance required for acceptable operational suitability and effectiveness. The objective value represents a measurable increase in capability that has practical operational benefit to the FAA and its customers. For example, an availability requirement may have a threshold of 90 percent and an objective goal of 95 percent.

B. Concept Paper Correlation Matrix

Develop a correlation matrix that maps by section number and need statement where every need in the Concept is addressed in the Requirements Document. Use table format.

C. Entity Relationship Diagrams

The diagrams in this appendix, if used, support the data requirements provided in Chapter 9.

D. Activity Diagrams

The diagrams in this appendix, if used, are a visual representation of the functional and interface requirements documented in Chapter 3. Ideally, these diagrams will be consistent with partitions used in the chapter.

E. Definitions



QPM #

AQS 200-001-WI

Revision

1



F. Acronyms

G. References Other documents or manuals that would be useful

H. Residual Technical Requirements

Specify those requirements from the Concept Paper that are not satisfied by the approved automation program. Resolution of these deferred requirements should occur via other Concept Papers or proposed product upgrades.

I. Planning Assumptions

Lists assumptions about requirements that are unknown or unspecified that will be used for project planning, scheduling, and resource estimating purposed.

13.11. EXAMPLES OF OPERATIONAL AND FUNCTIONAL REQUIREMENTSThe subsection titles in the following table are representative. Select and/or develop appropriate subtitles to describe operational and functional requirements for the candidate solution.

Subsection Title

3.1.1 Collection Data

3.1.1.1 Verify Data

3.1.1.1 Data

3.1.2 Report Activity

3.1.2.1 Summarize Activity Counts

3.1.2.2 Distribute Activity Reports

3.1.3 Display Information

3.1.3.1 Provide Selection Criteria

3.1.3.2 Display Selected Data

13.12. EXAMPLES OF CHARACTERISTICS AND PERFORMANCE REQUIREMENTSThe following subsection titles are representative. Select and/or develop titles appropriate to the candidate solution or acquisition program.

Subsection Heading Description

3.2.1 Service Levels

Define mission scenarios that may imply different levels of acceptable service (e.g., whether performance is different for normal and emergency back-up service, whether peak loading is substantially different from minimum or average loading).



QPM #

AQS 200-001-WI

Revision

1


3.2.2 Recovery Define the period of time for the product to recover full service after power loss.

3.2.3 Reliability, Maintainability, Availability

Define reliability requirements (e.g., mean time between failure (MTBF)). Define maintainability requirements (e.g., mean time to repair (MTTR)). Define availability requirements (e.g., full service availability, emergency service availability).

3.2.4 Enhanceability

Define requirements related to modularity and the ability of a product’s hardware and software components to be improved without requiring changes to components other than those being improved.

3.2.5 ScalabilityDefine requirements related to whether the product must provide for a range of capacity, functionality, and capability for a range of applications.

3.2.6 Operational SoftwareIdentify requirements concerning the selection of software (e.g., references to organizational software standards, whether software must be transferable between platforms).

3.2.7 Operational Hardware Define requirements concerning the selection of hardware (e.g., references to organizational standards).

3.2.7 TimelinessDefine requirements concerning how timely or current the information supporting this capability must (e.g., real-time, as of the last business).

13.13. REFERENCESThe main source for this SBD is the FAA’s AMS Template Requirements Document cited below. This template was modified to incorporate AVS automation program references. In addition, the AMS template was modified by incorporating functional integration into the technical performance section, by excluding in-service support, quality assurance, configuration management, and in-service management sections, and by adding sections on data and standards.

A list of the documents referenced follows:

Aircraft Certification Service. AVS Enterprise Software Development Life Cycle Standards (V 1.0) Dated 7/28/1997.

Carnegie Mellon University Software Engineering Institute. CMM Practices - Requirements Management. 1993.

Department of Justice. System Development Life Cycle Standards (SDLC). May 29, 1984.

FAA. Acquisition Management System Section 2.4 Investment Analysis. Revised June 1997.

FAA. Acquisition Management System Template Requirements Document. Dated 10/27/1997.



QPM #

AQS 200-001-WI

Revision

1


FAA. The Federal Aviation Administration Integrated Capability Maturity Model (FAA-iCMM), Version 1.0. November 1997.



QPM #

AQS 200-001-WI

Revision

1


14 COST-BENEFIT ANALYSIS

The Cost Benefit Analysis (CBA) analyzes and evaluates, from a cost perspective, the candidate solutions to meet the stated need. It will also describe the feasible alternatives, all tangible and intangible benefits, and the results of the analysis. The feasible alternatives are themselves documented in more detail in the companion feasibility study, shown in Appendix C-3, Feasibility Study. This CBA will discuss which system costs are analyzed, present the total costs for all the years the analysis covers, and outline the comparison between the costs of each alternative and the tangible benefits of the same.

This analysis will also state that the system being analyzed contributes to the mission and objectives of the AVS (or component).

Note: An urgent business need or external stakeholder pressure may dictate the use of an iterative alternative development work pattern that may not identify, evaluate, or document alternative solutions. If no feasible alternatives are identified, the CBA methodology must be tailored to evaluate the costs and benefits of the proposed IT investment, without extensive analysis of alternative solutions.

14.1. OVERVIEWThis section describes and discusses the value added to the systems project by the CBA, and the justification for it as documented in various OMB publications.

14.1.1. PurposeThis section discusses the business need the CBA is trying to address, that is, the decision the AVS (or component) is trying to make.

14.1.2. ScopeThis section states the scope of CBA.

14.1.3. MethodologyThis section describes and discusses the CBA methodology employed and its relationship to the SDLC work pattern to be used by the project team.

14.1.4. AVS NeedsThis section outlines the Program office(s) that will benefit from the new program or system and what mission and business process it will facilitate. This description should focus on the business needs/requirements the system is designed to meet.

14.1.5. BackgroundThis section chronicles the development of the system from System Concept Development Phase through its current status. This should be a descriptive account of how and why the system concept was envisioned. All system development efforts should be addressed, including any early prototypes or pilots and other contractor or agency efforts. The major functions and user requests are also included in the background.



QPM #

AQS 200-001-WI

Revision

1


Note: This section will be updated as the document is revised during the SDLC phases subsequent to System Concept Development Phase.

14.1.6. ArchitectureThis section describes, in a few sentences, the architecture on which the system will operate. This can be related to the local area network, wide area network, office automation, workstation, and e-mail architecture already in place at the locations of deployment. This section may need to be updated during the life of the system development project to include any changes or additions to the architecture.

14.1.7. Expected Useful LifeThis section briefly describes the expected useful life of the system. This section may need to be updated during the life of the system development project if any changes are projected for the expected useful life of the system.

14.2. OBJECTIVES AND PERFORMANCE MEASURESIn this section, objectives and performance measures are stated for the system to be developed. The specific objectives and performance measures that apply to this analysis will be noted in the exhibits in Sections 2.2, Strategic Objectives and Performance Measures, through 2.4, Tactical Objectives and Performance Measures.

14.2.1. Support for AVS MissionThis section describes how the project supports the Agency's Strategic Plans and overall mission.

14.2.2. Strategic Objectives and Performance MeasuresFigure 15-24: Strategic Level Performance Measures, outlines objectives and performance measures for the project at the strategic level that are outcome-based and mission-oriented. These measures should correlate to those shown in the System Boundary Document.

FIGURE 15-24: STRATEGIC LEVEL PERFORMANCE MEASURES

Name of System

Objective Performance Measure

14.2.3. Program Objectives and Performance MeasuresFigure 15-25: Program Level Performance Measures, outlines the objectives and performance measures of the project that reflect program outcomes directly supporting strategic level objectives.

FIGURE 15-25: PROGRAM LEVEL PERFORMANCE MEASURES

Name of System



QPM #

AQS 200-001-WI

Revision

1



14.2.4. Tactical Objectives and Performance MeasuresFigure 15-3, Tactical Level Performance Measures, outlines the objectives and performance measures for the project at the tactical (system) level. These system performance measures are primarily output-based and provide process linkage to the higher level, outcome-based programmatic and strategic measures.

FIGURE 15-26: TACTICAL LEVEL PERFORMANCE MEASURES

Name of System


14.3. ASSUMPTIONS, CONSTRAINTS, AND CONDITIONSThis section discusses assumptions, constraints, and conditions that may affect the results of this CBA. These assumptions, constraints, and conditions form the foundation on which the CBA is based; a change in any one of these could cause a change in benefits as well as costs.

14.3.1. AssumptionsThe assumptions are explicit statements used to describe the present and future environment on which an analysis is based. The assumptions relative to the project system may include:

All data (that is, cost figures, workload statistics, benefit values, etc.) used in this analysis are assumed to be accurate, reliable, and valid.

The results of this analysis could be skewed by inaccurate or different data.

14.3.2. ConstraintsThe constraints are factors, external to the program, which can limit the development of the application or the availability of performance data from the current system. The constraints relative to the project may include:

Any technology considered must be able to meet the minimum business requirements of the AVS (or components).

The programs and investments become cost ineffective if this is not the case.



QPM #

AQS 200-001-WI

Revision

1


14.3.3. ConditionsThe conditions are unique factors in the operating environment that may influence system processes. The conditions relative to the project may include:

The technology used must allow integration into the existing or proposed environment.

Redundant investment if more than one production platform is used

14.4. FEASIBLE ALTERNATIVESThis section identifies alternative solutions that will meet the needs and requirements outlined for the Program. The results of the corresponding Feasibility Study are used as a starting point into an analysis of costs and benefits for the Feasible Alternatives identified in that document. Each Feasible Alternative is analyzed as described in the subsequent sections.

This section discusses the Feasible Alternatives, which are technology solutions that meet the outlined high-level functional requirements. Feasible Alternatives will have been identified in a Feasibility Study (see Section 16). An individual description of each alternative is provided as well as specific assumptions, constraints, and conditions that are unique to each of the alternatives. Additionally, a list of advantages and disadvantages for each of the alternatives can be included in this section. A matrix is an effective way to depict these.

Note: An urgent business need or external stakeholder pressure may dictate the use of an iterative alternative development work pattern that may not identify, evaluate, or document alternative solutions. If no Feasible Alternatives are identified, mark this section as Not Applicable.

14.4.1. Alternative 1This section briefly describes the alternative, its components, and how it will work.

14.4.1.1. Assumptions, Constraints, and Conditions

This section describes the assumptions, constraints, and conditions specific to this alternative. The general assumptions, constraints, and conditions that apply to the entire analysis are contained in Section 14.3, Assumptions, Constraints, and Conditions.

FIGURE 15-27: ALTERNATIVE 1

Alternative 1

Assumptions Implications

Constraints Implications

Conditions Implications



QPM #

AQS 200-001-WI

Revision

1


14.4.1.2. Advantages and Disadvantages

This section discusses the advantages and disadvantages of this alternative.

FIGURE 15-28: ADVANTAGES AND DISADVANTAGES OF ALTERNATIVE 1

Advantages Disadvantages

Note: Repeat Section 4 for as many alternatives as exist for the Feasibility Study; for example,

Section 4.2 is for Alternative 2 up to Section 4.N for Alternative N.

14.5. COST ANALYSISThe Cost Analysis presents the costs for design, development, installation, operation, maintenance and disposal, and consumables for the system to be developed. This profile is used to analyze the costs of the system for each year in its life cycle, so those costs can be weighed against the benefits derived from using it. In accordance with OMB Circular A-94, the system is fully cost-accounted, including all spending resources, whether appropriated or non-appropriated.

14.5.1. Cost CategoriesFigure 15-29: Cost-Related Terms, defines cost-related terms used in the Cost Analysis [the suggested line items may not be a complete list]:

FIGURE 15-29: COST-RELATED TERMS

Terms and Definitions Line Item

Nonrecurring Costs: Nonrecurring costs are developmental and capital investment costs incurred only once during the analysis, design, development, and implementation of the system.

System developmentPrototypesHardware purchaseModule design, development, and

integrationSystem installation

Recurring Costs: Recurring costs are incurred more than once throughout the life of the system and generally include operation and maintenance costs.

Operations and MaintenanceTelecommunicationsSuppliesHardware and software upgrades,

maintenance, and licensesPersonnelTravel and training



QPM #

AQS 200-001-WI

Revision

1


14.5.2. Project Cost AnalysisThe costs for system design, development, installation, operations, and maintenance are presented in figure 15-7, Cost Analysis. This section gives a brief explanation of the cost calculations for each year.

This section explains that the costs for future years are discounted as per OMB A-94, Guidelines and Discount Rates for Benefit-Cost Analysis of Federal Programs. The Year of OMB Circular real discount rate for the number of years, and the percentage rate from OMB A-94, are used to derive the discount factors used in the cost calculations. Discount factors are applied to the future years to provide an appropriate net present value (NPV) for the system costs.

FIGURE 15-30: COST ANALYSIS

Alternative 1 Alternative 2 Alternative 3

Year One

Nonrecurring costs

Recurring costs

Year Two

Nonrecurring costs

Recurring costs

Year Three

Nonrecurring costs

Recurring costs

Total Costs

A detailed description of cost breakdowns should be developed to explain exactly how all cost calculations are presented. Discount rates should be applied where appropriate and documented as part of the explanation. Current OMB acceptable rates to be used can be found in a current version of the OMB Circular A-94. If necessary, a line-by-line cost accounting should be presented if the analysis is placed under any scrutiny.

14.6. BENEFIT ANALYSISThis section analyzes the alternatives' individual ability to meet the goals of the project.

14.6.1. Key Benefit TermsFigure 15-31: Key Benefit Terms, lists and defines key terms used in this section. Definitions for other terms used in this section may be found in Section 51, Glossary, and Section 52, Acronyms.

FIGURE 15-31: KEY BENEFIT TERMS

Term Definition



QPM #

AQS 200-001-WI

Revision

1


Tangible Benefits

Benefits are expressed in dollars or in units. The result of tangible benefits may be: increased revenue, streamlined production, or saved time and money. For purposes of this analysis, tangible benefits are expressed in dollar values so that a valid comparison can be made with costs.

The benefits for future years are discounted as per OMB A-94, Guidelines and Discount Rates for Benefit-Cost Analysis of Federal Programs.

Intangible Benefits

Benefits are expressed in terms of improved mission performance, Improved decision-making, or more reliable or usable information. These Benefits may be quantifiable, but cannot be expressed in dollar values.

Many public goods are difficult to reliably and validly quantify in dollar units; however, intangible benefits are vital to understanding the total Outcome of implementing a particular IT system.

14.6.2. Tangible BenefitsThis section provides a detailed description of the tangible benefits. Because each alternative may not provide the same benefits, it is necessary to note which alternatives provide which benefits. This section also describes, in detail, the source(s) of data used to quantify the benefit for each alternative and presents a chart that depicts the calculations for that benefit. It is important to provide sufficient documentation of data sources and calculations so that readers can follow the logic of the quantification of benefits.

Figure 15-32: Tangible Benefit 1, and Figure 15-33: Annual Savings (Based on Average X Million Transactions per Annum), detail this information. Repeat this for each tangible benefit.

FIGURE 15-32: TANGIBLE BENEFIT 1

Measurement

Current Value Alternative 1 Alternative n

Savings

FIGURE 15-33: ANNUAL SAVINGS (BASED ON AVERAGE X MILLION TRANSACTIONS PER ANNUM)

Annual Transaction Times

Current Alternative 1 Alternative n

Savings

FTE Savings

FTE Savings X FTEs Y FTEs

Dollar Savings (Based on FTE Salary of $X per Annum)



QPM #

AQS 200-001-WI

Revision

1


Dollar Savings

In a paragraph or two following the benefit description, each calculation should be explained and data sources, such as the current Federal general schedule, should be cited for any data used. Each benefit should be calculated out for the number of projected years for each alternative. Benefits and costs for each alternative should be calculated for the same number of years to provide an accurate cost benefit comparison.

14.6.3. Summary of Tangible BenefitsFigure 15-34: Tangible Benefits, summarizes the quantifiable benefit value for each alternative.

FIGURE 15-34: TANGIBLE BENEFITS

Alternative 1 Alternative n

Benefit 1

Benefit n

Total Benefit

Figure 15-35: Summary of Project Tangible Benefits: Expected Return, summarizes the tangible benefits described above.

Figure 15-36: Intangible Benefits Alternative 1, shows the expected return from tangible benefits for three years, allowing for an accurate comparison with the three year costs in Section 4, Feasible Alternatives. Figure 15-14, Intangible Benefits Alternative n, illustrates a comparison of the tangible benefits for each alternative as well as each technology solution as part of each alternative.

FIGURE 15-35: SUMMARY OF PROJECT TANGIBLE BENEFITS: EXPECTED RETURN

Tangible Benefit 1

FY99 FY00 FY01 Total

Alternative 1

Alternative n

Tangible Benefit n


Alternative 1

Alternative n

Total Benefits


Alternative 1

Alternative n



QPM #

AQS 200-001-WI

Revision

1


If any of the alternatives does not provide one of the benefits, be sure to indicate this by placing a zero in the box and providing a brief explanation of why.

14.6.4. Intangible BenefitsAlthough no quantifiable dollar value has been placed on these benefits, if data are available in the future, it will be possible to quantify some of these intangible benefits. The intangible benefits for each alternative may either be the same or different. It is important to include all intangible benefits.

FIGURE 15-36: INTANGIBLE BENEFITS ALTERNATIVE 1

Intangible Benefits Description

Intangible Benefit 1

Intangible Benefit n

FIGURE 15-37: INTANGIBLE BENEFITS ALTERNATIVE N

Intangible Benefits Description



For each alternative, include a table in the same format as the above exhibits.

14.6.5. Summary of Intangible BenefitsFigure 15-38: Summary of Intangible Benefits-- Expected Return, summarizes the values of intangible benefits.

FIGURE 15-38: SUMMARY OF INTANGIBLE BENEFITS-- EXPECTED RETURN

Intangible Benefits Alternative 1 Alternative n



This table should be used to indicate if an alternative provides an intangible benefit for comparison purposes. A checkmark can be placed in each alternative box that does provide the particular benefit. It should be noted that if an intangible benefit can be valued in unit terms but cannot be valued in dollars, the unit valuation should be presented in some manner and the alternatives should be ranked for that intangible alternative.

14.7. COMPARISON OF COSTS AND BENEFITSThis section compares the costs and benefits for the project. The first part of the comparison examines the tangible benefits and the second part examines intangible benefits. The purpose of this comparison is to identify if tangible and intangible benefits outweigh the total cost of the system.



QPM #

AQS 200-001-WI

Revision

1


14.7.1. Tangible BenefitsFigure 15-39: Project Cost to Tangible Benefit Comparison, compares the costs and tangible benefits of the Project.

FIGURE 15-39: PROJECT COST TO TANGIBLE BENEFIT COMPARISON


Total Tangible Benefits

Total Costs

Difference Between Costs and Benefits

14.7.2. Intangible BenefitsFigure 15-40: Intangible Benefit Comparison-- Expected Return, compares the intangible benefits of the Project.

FIGURE 15-40: INTANGIBLE BENEFIT COMPARISON-- EXPECTED RETURN


Intangible Benefits

14.7.3. ConclusionAs with any investment analysis, it is important to note that any changes in program assumptions, conditions, or constraints should drive a reassessment of the analysis to reevaluate the effects of these changes.

14.8. SENSITIVITY ANALYSISA sensitivity analysis assesses the potential effect on inputs (costs) and outcomes (benefits) that depends on the relative magnitude of change in certain factors or assumptions. A change in any factor (that is, area of uncertainty) can necessitate a revision to the cost-benefit projections or can influence system performance outcomes. This section examines key sources of uncertainty in the operational environment of the Project and what it is going to do. This may also rank the alternatives and see how sensitive they are to basic assumptions or externalities (political, social, and environmental). After costs and benefits are determined for each alternative, the alternatives are ranked and a sensitivity analysis is performed.

14.8.1. Key Sources of UncertaintyFigure 15-41: Sensitivity Results, lists the key factors that have implications for the Project.

Projected costs and benefits could change depending on the extent of change in these factors.

FIGURE 15-41: SENSITIVITY RESULTS

Key Sources of Uncertainty

Extent of Impact

Nature of Impact

Implications



QPM #

AQS 200-001-WI

Revision

1


14.8.2. Sensitivity ResultsEach of the key sources of uncertainty could have an effect on the benefits and costs of the project. The effect of each source of uncertainty is discussed in the subsequent section.

14.9. RESULTS OF THE ANALYSISThe project CBA results are based on the work described in the previous sections. This work assesses the costs and benefits, both tangible and intangible, of the project and what it will do. The sensitivity of its costs and benefits to key sources of uncertainty are described in Section 8, Sensitivity Analysis. This section should list what the system will provide the agency. It should also discuss how well each alternative would achieve the goals of the system in context to the relative cost of that alternative. No specific recommendation should be made. Decision makers should use any CBA as a tool in conjunction with other studies and factors to determine the most appropriate investment choice for the agency to achieve its mission.

14.10. REFERENCES AND DOCUMENTATIONDocuments used to obtain information for this CBA, including project alternatives, costs, benefits, uncertainties, and information regarding cost-benefit methodologies, are listed in the subsequent sections.

14.10.1. DocumentationList all documents used for this analysis. This list should include titles, authors, publishers, and dates.

14.10.2. InterviewsList all interviews conducted for this analysis. This list should include names and organizations.

14.11. GLOSSARY AND ACRONYMSThe definitions and acronyms presented in this section are specific to this analysis. Although these terms and acronyms may have other meanings, those included in the subsequent sections are used in this analysis.

14.11.1. GlossaryProvide a list of all system-specific terms, and their definitions, used in this document.

14.11.2. AcronymsProvide a list of all acronyms used in this document.

14.12. COST-BENEFIT ANALYSIS OUTLINECover Page

Table of Contents

Executive SummaryUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


1.0 Overview

1.1 Purpose

1.2 Scope

1.3 Methodology

1.4 AVS Needs

1.5 Background

1.6 Architecture

1.7 Expected Useful Life

2.0 Objectives and Performance Measures

2.1 AVS Mission

2.2 Strategic Objectives and Performance Measures

2.3 Program Objectives and Performance Measures

2.4 Tactical Objectives and Performance Measures

3.0 Assumptions, Constraints, and Conditions

3.1 Assumptions

3.2 Constraints

3.3 Conditions

4.0 Feasible Alternatives (If Applicable)

4.1 Alternative 1 (repeat, as necessary, for additional alternatives)

4.1.1 Assumptions, Constraints, and Conditions-- Alternative 1

4.1.2 Advantages and Disadvantages-- Alternative 1

5.0 Cost Analysis

5.1 Cost Categories

5.2 Project Cost Analysis

6.0 Benefit Analysis

6.1 Key Benefit Terms

6.2 Tangible Benefits (repeat, as necessary, for additional benefits)

6.3 Summary of Tangible Benefits

6.4 Intangible Benefits

6.5 Summary of Intangible Benefits

7.0 Comparison of Costs and Benefits for Project



QPM #

AQS 200-001-WI

Revision

1


7.1 Results of the Comparison for Project-- Tangible Benefits

7.2 Results of the Comparison for Project-- Intangible Benefits

7.3 Conclusion

8.0 Sensitivity Analysis

8.1 Key Sources of Uncertainty

8.2 Sensitivity Results

9.0 Results of the Analysis

10.0 References and Documentation

10.1 Documentation

10.2 Interviews

11.0 Glossary and Acronyms

11.1 Glossary

11.2 Acronyms



QPM #

AQS 200-001-WI

Revision

1


15 FEASIBILITY STUDY

The Feasibility Study describes the information management or business requirement or opportunity in clear, technology-independent terms on which all affected organizations can agree. An information management requirement or opportunity can be prompted by such factors as new legislation, changes to regulations, or the growth of a program beyond the support capability of existing systems.

The Feasibility Study provides an overview of a complex business requirement or opportunity and determines if feasible solutions exist before full life-cycle resources are committed. The requirement or opportunity is assessed in terms of technical, economic, and operational feasibility. The study contains decision criteria, comparisons of general solution possibilities, and a proposed program (solution). The study is conducted any time a broad analysis is desired before commitment of development resources. Before conducting the study, the following key decisions should be addressed:

What is the specific requirement or opportunity and the responsible organization(s)? Provide an initial recognition of the requirement or opportunity and establish the broad objectives of the remainder of the life cycle. This decision addresses characteristics of the requirement or opportunity, such as programmatic or other causes and symptoms of the requirement or opportunity, affected organizations, types of information needed, high-level information processing capabilities, an initial perception of the ability of current systems and procedures to address the requirement or opportunity, and the timeframe(s) within which the requirement or opportunity must be resolved.

What new information needs are associated with the problem? Provide a context for future life-cycle decisions by determining if a new information need exists to support a solution. Describe the scope of the need in terms of missions and organizations affected.

How broad a scope should the solution cover? Provide an overall context within which potential solutions to the requirement are defined, helping to ensure that solutions focus on the major priority areas. The scope is determined in terms of the organization(s), such as agency offices, congressional organizations, or executive branch agencies; the pertinent portions of the missions or programmatic functions of each organization; and the potential relationship of the current requirement and efforts to formulate its solution to other previously identified requirements and ongoing related efforts.

A CBA is prepared as a companion document with the feasibility study. The CBA is the document that provides managers with adequate cost and benefit information to analyze and evaluate alternative approaches. It provides information for management to make decisions to initiate a proposed program-- to continue or discontinue the development, acquisition, or modification of information systems or resources.

A sample outline of a feasibility study is provided.



QPM #

AQS 200-001-WI

Revision

1


15.1. INTRODUCTION15.1.1. Origin of RequestThis section identifies the originator and describes the circumstances that precipitated this project request. Provide the objectives of the Feasibility Study in clear, measurable terms.

15.1.2. Explanation of RequirementThis section describes the information management requirement in programmatic, technology-independent terms. It should state the specific deviations from the desired situation and the source and/or cause of the new requirement or opportunity. It describes any new information need(s) associated with the requirement or opportunity. The section should identify the cause(s) and effect(s) of the requirement or opportunity and validate the description of the requirement or opportunity with all affected organizations.

15.1.3. Organization InformationThis section identifies the organization(s) mentioned in Section 1.1, Origin of Request, and the pertinent current procedures, information, and systems of those organizations. Provide descriptions of the relevant procedures and systems as appropriate.

The section should specify all organizational units involved, list the organizational unit(s) at all levels of the Service and external organizations that relate to the requirement or opportunity, and describe the pertinent mission area(s) and programmatic functions of each.

15.1.4. GlossaryProvide a glossary of all terms and abbreviations used in the Feasibility Study. If the glossary is several pages in length, include it as an appendix to the study.

15.2. EVALUATION CRITERIAThis section states the criteria by which the alternatives will be evaluated. The criteria should make a distinction among characteristics that must be present in the system for it to be acceptable.

15.3. ALTERNATIVE DESCRIPTIONSThis section provides a description for each alternative proposed to handle the defined problem. It should describe the resources required, associated risk, system architecture, technology used, and the manual process flow for each alternative. The section should state at least two alternatives for each feasibility study-- one being the alternative of doing nothing, if appropriate-- and predict the anticipated benefits of each alternative and the likely effects of not taking action on the alternative. The section should also state benefits in terms of technical, operational, and economic feasibility.

15.3.1. Alternative ModelThis section presents a high-level data flow diagram and logical data model, if possible, from current physical processes and data for the proposed system alternative.



QPM #

AQS 200-001-WI

Revision

1


15.3.2. DescriptionThis section states the required and desirable features, and provides a concise narrative of the effects of implementing this alternative.

15.4. ALTERNATIVE EVALUATIONThis section provides a systematic comparison of the alternatives and documents potential problems resulting from the implementation of each.

15.5. RECOMMENDATIONThis section provides a narrative that supports the recommended alternative program. The section should select the most advantageous program to implement the required functional capabilities based on the functional and technical concepts that satisfy the need. The information system should not be obtained at the price of inappropriate development risk or the loss of efficiency, capability, or capacity in the supported function.

15.6. FEASIBILITY STUDY OUTLINECover Page

Table of Contents

1.0 Introduction

1.1 Origin of Request

1.2 Explanation of Requirement

1.3 Organization Information

1.4 Glossary

2.0 Evaluation Criteria

3.0 Alternative Descriptions

3.1 Alternative Model

3.2 Description

4.0 Alternative Evaluation

5.0 Recommendation



QPM #

AQS 200-001-WI

Revision

1


16 RISK MANAGEMENT PLAN

16.1. INTRODUCTION16.1.1. PurposeIn this section, present a clear, concise statement of the purpose of the Risk Management (RM) plan. Include the name and code name of the project, the name(s) of the associated system(s), and the identity of the organization that is responsible for writing and maintaining the RM plan.

16.1.2. BackgroundThis section briefly describes the history of the project and the environment in which the project will operate. (This information may be included through reference to other project documents.) Include the following information:

Identification of other systems with which the subject system interfaces Contractor support for development and maintenance System architecture, operating system, and application languages Development methodology and tools used for the project

16.1.3. ScopeThis section presents a definitive statement of the scope of the RM planning contained in this document, including the limits and constraints of the RM plan.

16.1.4. PolicyInclude in this section policy decisions that affect how RM is conducted. This section also lists documents that are referenced to support the RM process. Include any project or standards documents that are referenced in the body of the plan or that have been used in the development of the document.

16.1.5. ApproachIn this section, describe the project's approach to risk management. Include the elements of identification, analysis, planning, tracking, control, and communications. Discuss the project's risk mitigation strategies in general and detail specific strategies that have significant impact across the project (e.g., parallel development, prototyping).

16.2. RISK IDENTIFICATION LISTThe tracking of risks in a risk identification list is a critical facet of successful system development management. The risk identification list is used from the beginning of the project and is a major source of input for the risk assessment activity. Following are examples of categories that may be a source of risk for a system development:

The complexity, difficulty, feasibility, novelty, verifiability, and volatility of the system requirements



QPM #

AQS 200-001-WI

Revision

1


The correctness, integrity, maintainability, performance, reliability, security, testability, and usability of the SDLC deliverables

The developmental model, formality, manageability, measurability, quality, and traceability of the processes used to satisfy the customer requirements

The communication, cooperation, domain knowledge, experience, technical knowledge, and training of the personnel associated with technical and support work on the project

The budget, external constraints, politics, resources, and schedule of the external system environment

The capacity, documentation, familiarity, robustness, tool support, and usability of the methods, tools, and supporting equipment that will be used in the system development

Once the risks have been identified, document them in this section as the risk identification list. Steps for developing the risk identification list are the following:

Number each risk using sequential numbers or other identifiers.

Identify the SDLC document in which the risk is applicable. For instance, if you are working on the CM plan and discover a CM risk, identify the CM plan as the related document.

Describe the risk in enough detail that a third party who is unfamiliar with the project can understand the content and nature of the risk.

Use the risk identification list throughout the life-cycle phases to ensure that all risks are properly documented.

16.3. RISK ASSESSMENTThe project management plan and the risk identification list are inputs to the risk assessment. Categorize the risks as internal or external risks. Internal risks are those that you can control. External risks are events over which you have no direct control. Examples of internal risks are project assumptions that may be invalid and organizational risks. Examples of external risks are Government regulations and supplier performance.

Evaluate the identified risks in terms of probability and impact. For each risk item, determine the probability that this will occur and the resulting impact if it does occur.

Use an evaluation tool to score each risk. For example, a simplistic model could be:

Assign numerical scores to risk probability (1=low, 2=moderate, 3=high) and severity of impact (1=low, 2=moderate, 3=high). A risk score would be the product of the two scores. Management attention would be then be focused on those risks with a score of 9, followed by 6, etc.

16.4. RISK ACTION PLANReview the risk items with high rankings from Section 3 and determine if the significant risks will be accepted, transferred, or mitigated. With the acceptance approach, no effort is made to avoid the risk item. This approach is usually employed because the risk items are the result of external factors over which you have no direct control. Two types of action are usually taken under the acceptance approach: contingency planning and no action. You can plan



QPM #

AQS 200-001-WI

Revision

1


contingencies in case the risk does occur. Thus, the project team has a backup plan to minimize the affects of the risk event. Or you can take no action and accept responsibility if the risk event does indeed occur. With the transfer approach, the objective is to reduce risk by transferring it to another entity that can better bear it. Two methods of transferring risk are the use of insurance and the alignment of responsibility and authority. With the mitigation approach, emphasis is on actually avoiding, preventing, or reducing the risk. Some risks can be avoided by reducing the number of requirements or defining them more completely. For example, careful definition of the scope of a project in a SOW can avoid the possible consequence of "scope creep," or indecisive, protracted, and uncertain scope objectives. In this section, identify and describe in detail the actions that will be taken to transfer or mitigate risks that are prioritized as high in Section 3. These actions should ultimately result in the reduction of project risk and should directly affect the project plan and the metrics used for the project. Activities for reducing the effects of risk will require effort, resources, and time just like other project activities. The actions need to be incorporated into the budget, schedule, and other project plan components. Update the project plan components to ensure the planning and execution of risk action activities. Also, refer to contingency plan documents for any contingency plans that have been identified with the risk acceptance approach. Risk action plans will be used to direct all risk mitigation activities. The RM plan will need to be monitored and updated throughout the life-cycle phases.

16.5. RISK MANAGEMENT OUTLINE1.0 Introduction

1.1 Purpose

1.2 Background

1.3 Scope

1.4 Policy

1.5 Approach

2.0 Risk Identification List

3.0 Risk Assessment

4.0 Risk Action Plan



QPM #

AQS 200-001-WI

Revision

1


17 ACQUISITION PLAN

The Acquisition Plan is a document that shows how all government human resources, hardware, software, and telecommunications capabilities, along with contractor support services, are acquired during the life of the project. The Acquisition Plan helps ensure that needed resources can be obtained and is available at the time they are needed. The plan includes a milestone schedule that lists activities for completion and deliverables to be produced with appropriate estimated completion dates. Follow the applicable elements of the outline to complete the Acquisition Plan. The information in the plan is as follows:

Provides management with adequate information for making decisions concerning procurement of government human resources and services, contractor services procurement, including ensuring the availability of funding

Provides technical evaluation personnel with adequate information for analyzing and evaluating vendor proposals

Ensures that vendors will have adequate information for preparing bids Provides the source selection official with adequate information on which to base

a selection The following should be considered when submitting a request for hardware,

software, and/or related services requiring AIS pre-acquisition authority, per the AVS 1986 mandate:

Resources are consistent with applicable laws, regulations, policy/procedural guidance from central management agencies, Congress, and senior department management.

Acquisitions are consistent with departmental objectives and initiatives as defined in the AVS plans.

AIS resources are obtained only in direct support of the AVS missions and programs of the acquiring office/organization.

Acquisitions are not redundant or duplicative efforts resulting in wasted money, time, and resources.

AIS resources represent the most efficient and cost-effective means of providing automated support.

The Acquisition Plan typically has its own mini-life cycle of pre-solicitation, solicitation and award, and post award. The life-cycle model varies according to the system development effort; this means that the activities in each differ. The model Acquisition Plan includes a milestone schedule, with estimated completion dates, for the following activities:

Requirements Analysis Analysis of Alternatives Statement of Work (SOW) Procurement of government human resources and services Procurement plan



QPM #

AQS 200-001-WI

Revision

1


Acquisition of contractor services Legal opinion on statement of work Solicitation of services Technical evaluation report Source selection recommendation Contract award Adjustment of funds Contract performance

For completion of these activities, refer to guidelines for acquiring Federal information processing resources and AVS acquisition procurement regulations.

The Acquisition Plan becomes critical after the functional requirements document has been approved. Several acquisitions may be needed to procure an entire system and will be a continuous part of the cycle. The Acquisition Plan is continuously updated, and the involvement of users working closely with the Project Manager the Acquisition personnel becomes increasingly important as the project progresses. The Project Manager works directly with the Acquisition personnel to ensure the timely award of the needed resources. The Acquisition Plan is developed as required by the Federal Acquisition Regulation (FAR) 7.103 using the following format.

17.1. BACKGROUND AND OBJECTIVES17.1.1. Statement of NeedThis section introduces the plan with a brief statement of need. This section should discuss feasible acquisition alternatives and any related in-house efforts.

17.1.2. Applicable ConditionsThis section states all the significant conditions affecting the acquisition, including requirements for compatibility with existing or future systems or programs and any known cost, schedule, and capability or performance constraints.

17.1.3. CostThis section sets forth the established cost goals for the acquisition and the rationale supporting them, and discusses related cost concepts to be employed, as indicated in the subsequent sections. In each subsection, discuss the type of funding that will be required.

17.1.4. Life-Cycle CostThis section discusses how the life-cycle cost will be considered. If life-cycle cost is not used, this section explains why. This section also discusses, if appropriate, the cost model used to develop the life cycle cost estimates. Life-cycle cost is the total cost to the Government of acquiring, operating, supporting, and disposing of the items being acquired.



QPM #

AQS 200-001-WI

Revision

1


17.1.5. Design-to-CostThis section discusses the design-to-cost objectives and the underlying assumptions, including the rationale for quantity, learning curve, and economic adjustment factors. It describes how objectives are to be applied, tracked, and enforced, and indicates the specific related solicitation and contractual requirements to be imposed. Design-to-cost is a concept that establishes cost elements as management goals to achieve the best balance between life-cycle cost, acceptable performance, and schedule. Under this concept, cost is a design constraint during the design and development phases, and a management discipline throughout the acquisition and operation of the system or equipment.

17.1.6. Application of Should-CostThis section discusses the application of should-cost analysis to the acquisition, as per FAR 15.810.

17.1.7. Capability or PerformanceThis section specifies the required capabilities or performance characteristics of the products being acquired, and states how they are related to the need.

17.1.8. Delivery or Performance-Period RequirementsThis section describes the basis for establishing delivery or performance-period requirements, and explains and provides reasons for any urgency resulting in concurrency of development or justifying other than full and open competition.

17.1.9. Trade-OffsThis section discusses the expected consequences of trade-offs among the various cost, capability, performance, and schedule goals.

17.1.10. RisksThis section discusses the technical, cost, and schedule risks and describes what efforts are planned or underway to reduce the risk and the consequences of failure to achieve goals. The effects on cost and schedule risks imposed by concurrency of development and production should also be discussed, if applicable.

17.1.11. Acquisition StreamliningThis section is included if the acquisition has been designated as part of a program subject to acquisition streamlining. It discusses plans and procedures to encourage industry participation via draft solicitations, pre-solicitation conferences, and other means of stimulating industry involvement during design and development. It also discusses plans and procedures for selecting and tailoring only the necessary and cost-effective requirements, and it states the time frame for identifying which specifications and standards, that had originally been provided for guidance only, are scheduled to become mandatory.



QPM #

AQS 200-001-WI

Revision

1


17.2. PLAN OF ACTION17.2.1. SourcesThis section indicates the prospective sources of products than can meet the need. It considers the required sources, including consideration of small businesses, small disadvantages businesses, and women-owned small business concerns. It addresses the results of market research and analysis and indicates their effect on the various elements of the plan.

17.2.2. CompetitionThis section describes how competition will be sought, promoted, and sustained throughout the course of the acquisition. If the acquisition will be other than a full and open competition, this section cites the authority for the deviation, discusses the basis for the application of the authority, identifies the sources, and discusses why full and open competition cannot be obtained. This section also identifies the major components of the subsystems, and describes how competition will be sought, promoted, and sustained for these components. This section also discusses how competition will be sought, promoted, and sustained for spares and repair parts. This includes an identification of the key logistic milestones, such as technical data delivery schedules and acquisition method coding conferences, which affect competition. Finally, if subcontract competition is feasible and desirable, this section describes how such subcontract competition will be sought, promoted, and sustained throughout the course of the acquisition, and how any known barriers to subcontract competition will be overcome.

17.2.3. Source Selection ProceduresThis section discusses the source selection procedures for the acquisition, including the timing for submission and evaluation of proposals, and the relationship of evaluation factors to the attainment of the acquisition objectives.

17.2.4. Contracting ConsiderationsThis section discusses, for each contract contemplated, the contract type selection; the use of multi-year contracting; options; or other special contracting methods; any special clauses, special solicitation provisions, FAR deviations required; if sealed bidding or negotiation will be used, and why; if equipment will be acquired by lease or purchase, and why; and any other contracting considerations.

17.2.5. Budgeting and FundingThis section describes how budget estimates were derived, and discusses the schedule for obtaining adequate funds at the time they are required.

17.2.6. Product DescriptionsThis section explains, in accordance with FAR Part 11, the choice of product description types to be used in the acquisition.



QPM #

AQS 200-001-WI

Revision

1


17.2.7. Priorities, Allocations, and AllotmentsThis section specifies the method for obtaining and using priorities, allocations, and allotments, and the reasons for them, in cases where the urgency of the requirement dictates a short delivery or performance schedule.

17.2.8. Contractor versus Government PerformanceThis section addresses the consideration given to OMB Circular A-76. Circular A-76 indicates that it is the policy of the Government to rely generally on private commercial sources for supplies and services, when certain criteria are met, while recognizing that some functions are inherently governmental and must be performed by Government personnel. It also gives consideration to relative cost when deciding between Government performance and performance under contract.

17.2.9. Inherently Governmental FunctionsThis section addresses the considerations given to Office of Federal Procurement Policy Letter 92-1. Inherently governmental functions are those functions that, as a matter of policy, are so intimately related to the public interest as to mandate performance by Government employees.

17.2.10. Management Information RequirementsThis section discusses the management systems that will be used by the Government to monitor the contractor's effort.

17.2.11. Make or BuyThis section discusses considerations given to make-or-buy programs, as per FAR 15.7.

17.2.12. Test and EvaluationThis section describes the test program of the contractor and the Government. It describes the test program for each major phase of a major system acquisition. If concurrent development/deployment is planned, this section discusses the extent of testing to be accomplished before production release.

17.2.13. Logistics ConsiderationsThis section describes the assumptions determining contractor or agency support, initially and over the life of the acquisition, including contractor or agency maintenance and servicing and distribution of commercial items. It also describes the reliability, maintainability, and quality assurance requirements, including any planned use of warranties. It also describes the requirements for contractor data and data rights, their estimated cost, and the use to be made of the data. And, it describes standardization, including the necessity to designate technical equipment as "standard" so that future purchases of the equipment can be made from the same manufacturing source.

17.2.14. Government-Furnished PropertyThis section indicates the property to be furnished to contractors, including material and facilities, and discusses associated considerations, such as availability, or the schedule for its acquisition.



QPM #

AQS 200-001-WI

Revision

1


17.2.15. Government-Furnished InformationThis section discusses any Government information, such as manuals, drawings, and test data, to be provided to prospective offerors and contractors.

17.2.16. Environmental and Energy Conservation ObjectivesThis section discusses all applicable environmental and energy conservation issues associated with the acquisition, the applicability of an environmental assessment or environmental impact statement, the proposed resolution of environmental issues, any environmentally related requirements to be included in solicitations and contracts.

17.2.17. Security ConsiderationsThis section discusses, for acquisitions dealing with security-related matters, how adequate security will be established, maintained, and monitored.

17.2.18. Other ConsiderationsThis section discusses, as applicable, other considerations, such as standardization concepts, the industrial readiness program, the Defense Production Act, the Occupational Safety and Health Act, foreign sales implications, and any other matters germane to the plan and not covered elsewhere.

17.2.19. Milestones for the Acquisition CycleThis section addresses the following steps, and any others as appropriate: Acquisition Plan approval; statements of work (SOWs); specifications; data requirements; completion of acquisition package preparation; purchase requests; justification and approval for other than full and open competition; issuance of synopsis; issuance of solicitation; evaluation of proposals, audits, and field reports; beginning and completion of negotiations; contract preparation, review, and clearance; and contract award.

17.2.20. Acquisition Plan ContactsThis section lists the individuals who participated in preparing the Acquisition Plan, and provides contact information for each.

17.3. ACQUISITION PLAN OUTLINECover Page

Table of Contents

1. Background and Objectives

1.1 Statement of Need

1.1.1 Acquisition History

1.1.2 Feasible Acquisition Alternatives

1.2 Applicable Conditions

1.3 Cost(s)



QPM #

AQS 200-001-WI

Revision

1


1.3.1 Life Cycle Cost(s)

1.3.2 Design-to-Cost

1.3.3 Application of Should-Cost

1.4 Capability or Performance

1.5 Delivery or Performance-Period Requirements

1.6 Trade-Offs

1.7 Risks

1.8 Acquisition Streamlining

2. Plan of Action

2.1 Sources

2.2 Competition

2.3 Source-Selection Process

2.4 Contracting Considerations

2.5 Budgeting and Funding

2.6 Product Descriptions

2.7 Priorities, Allocations and Allowances

2.8 Contractor vs. Government Performance

2.9 Inherently Governmental Functions

2.10 Management Information Requirements

2.11 Make or Buy

2.12 Test and Evaluation

2.13 Logistics Considerations

2.14 Government Furnished Property

2.15 Government Furnished Information

2.16 Environmental and Energy Conservation Objectives

2.17 Security Considerations

2.18 Other Considerations

2.19 Milestones for the Acquisition Cycle

2.20 Acquisition Plan Contacts



QPM #

AQS 200-001-WI

Revision

1


18 CONFIGURATION MANAGEMENT PLAN

18.1. INTRODUCTIONProvide a brief statement that introduces the Configuration Management (CM) plan and describes, in general terms, its use in managing the configuration of the specific project, or system.

18.1.1. PurposeDescribe why this CM plan was created, what it accomplishes, and how it is used.

18.1.2. ScopeDefine the scope of CM planning.

18.1.3. System DescriptionBriefly describe the system, its history, and the environment in which the project operates (mainframe, client/server, or stand alone). Describe the system architecture, operating system, and application languages. Identify other legacy or new systems with which this system interfaces. List the number of sites that are using the system.

18.1.4. DefinitionsDefine the terms that appear in the CM plan.

18.1.5. Reference DocumentsList the documents that are referenced to support the CM process including any project or standards documents referenced in the body of the CM plan.

18.2. ORGANIZATIONIdentify the organization in which CM resides and all organization units that participate in the project. Define the functional roles of these organizational units within the project structure.

18.2.1. CM ActivitiesIdentify all CM functions required to manage the configuration of the system.

18.2.2. CM ResponsibilitiesList CM responsibilities that are required to support this project.

18.3. CONFIGURATION IDENTIFICATIONExplain that Configuration Identification is the basis on which the configuration items (CIs) are defined and verified; CIs and documents are labeled; changes are managed; and accountability is maintained. Define the automated tools that will be used to track and control the configuration baselines.



QPM #

AQS 200-001-WI

Revision

1


18.3.1. Configuration Item IdentificationIdentify the CIs to be controlled and specify a means of identifying changes to the CIs and related baselines.

18.3.2. Identification ConventionsDescribe the identification (numbering) criteria for the software and hardware structure, and for each document or document set.

18.3.3. Naming ConventionsProvide details of the file naming convention to be used on the project and how file configuration integrity will be maintained.

18.3.4. LabelsDescribe the requirements for labeling media and application software.

18.3.5. Configuration Baseline ManagementDescribe what baselines are to be established. Explain when and how they will be defined and controlled.

18.4. CONFIGURATION CONTROLExplain that configuration change management is a process for managing configuration changes and variances in configurations.

18.4.1. Change ManagementDefine the process for controlling changes to the system baselines and for tracking the implementation of those changes.

18.4.2. Review and Control Board(s)Describe any Internal Review Boards and Configuration Control Boards that will be established for the project. For each board, discuss the members who will participate (and their functional representatives), the Chair, the Secretariat, and the responsibilities of the board and of each member to the board.

18.4.3. Interface ManagementIdentify the interfaces to be managed and describe the procedures for identification of interface requirements, establishment of interface agreements, and participation in any Interface Control Working Groups.

18.5. CONFIGURATION STATUS ACCOUNTINGExplain that Configuration Status Accounting (CSA) is the process of keeping records of all change actions pertaining to a configuration item to generate reports on all decisions made and implemented. Also, show that CSA provides a means of storing and cross-referencing the collected data.



QPM #

AQS 200-001-WI

Revision

1


18.6. CONFIGURATION AUDITSDescribe how peer review audits and formal audits will be accomplished.

18.7. REVIEWSDescribe how the technical reviews relate to the establishment of baselines and explain the role of CM in these reviews.

18.8. CM PLAN MAINTENANCEDescribe the activities and responsibilities necessary to ensure continued CM planning during the life cycle of the project. State who is responsible for monitoring the CM plan. Describe how frequently updates are to be performed; how changes to the CM plan are to be evaluated and approved; and how changes to the CM plan are to be made and communicated.

18.9. DATA MANAGEMENT

18.9.1. LibrariesIdentify the libraries and the media under control, the requirements for the control of documentation, and how access control is to be managed.

18.9.2. Automated ToolsDescribe any automated tools used.

18.9.3. Version ControlDescribe the processes in place to control the amount and number of versions documented by this CM Plan.

18.9.4. Work Space ManagementDescribe the processes used for automated software source case control tools.

18.9.5. Build ManagementDescribe the controls in place to manage the building of executable code.

18.9.6. Documentation ManagementDescribe the processes in place for documentation management and who is responsible for them.

18.10. SUBCONTRACTOR CONTROLSubcontractors will be required to meet the CM requirements that have been levied by the plan on the contractor. The requirements for the subcontractor may be modified to fit the scope and magnitude of the subcontract task. A complete CM plan should be required of the subcontractor if an extensive contract is envisioned. If the contract is minor in content a plan should not be requested. However, provisions must be made for continuous communication and monitoring of CM activities, review and disposition of subcontractor supplied documents and subsequent changes, and the final audits. Subcontractors will provide status accounting reports reflecting the development of software, hardware, and COTS Configuration Item data.



QPM #

AQS 200-001-WI

Revision

1


18.11. CONFIGURATION MANAGEMENT PLAN OUTLINECover Page

Approval/Signatures

Change History Page

Table of Contents

1. Introduction

1.1 Purpose

1.2 Scope

1.3 System Description

1.4 Definitions

1.5 Reference Documents

2. Organization

2.1 Configuration Management Activities

2.2 Configuration Management Responsibilities

3. Configuration Identification

3.1 Configuration Item Identification

3.2 Identification Conventions

3.3 Naming Conventions

3.4 Labels

3.5 Configuration Baseline Management

4. Configuration Control

4.1 Change Management

4.2 Review and Control Board(s)

4.3 Interface Management

5. Configuration Status Accounting

6. Configuration Audits

7. Reviews

8. Configuration Plan Maintenance

9. Data Management

9.1 Libraries

9.2 Automated Tools



QPM #

AQS 200-001-WI

Revision

1


9.3 Version Control

9.4 Work Space Management

9.5 Build Management

9.6 Documentation Management

10. Subcontractor Control



QPM #

AQS 200-001-WI

Revision

1


19 QUALITY ASSURANCE PLAN

The purpose of the Quality Assurance (QA) plan is to ensure that delivered products satisfy contractual agreements, meet or exceed quality standards, and comply with approved SDLC processes.

The delivered QA plan will include a Program Level plan and Project plan(s). The Program Level plan describes all potential activities that QA could apply to a program's tasks as they proceed through the life cycle. The Project Level QA plan(s) will describe the actual QA activities that will be integrated with the project plan and schedule. The level of detail contained in the Project Level QA plan(s) should be consistent with the complexity, size, intended use, mission criticality, and cost of failure of the system development effort. Only deviations from the Program Level QA plan and special characteristics appropriate to the task are required for completion of the Project Level QA plan(s).

The suggested format, Quality Assurance Plan Outline, is applicable to both Program Level and Project Level plans.

19.1. GENERAL

19.1.1. PurposeEstablish the requirements for QA applicable to all portions of the system's development effort.

QA activities will require effort, resources, and time just like other project activities.

19.1.2. Reference(s)List documents used in QA reviews with complete citations (title; version number, if any; originating organization; date; etc.). References should include all standards that will apply to the QA function.

19.1.3. ObjectiveDiscuss the system QA objectives of the program as established by the Project Manger. Describe the benefits that will be realized by conforming to quality requirements and the contributions that QA makes to the success of the program.

19.1.4. GlossaryProvide definitions for terms and acronyms used within the QA plan.

19.2. ORGANIZATIONProvide an operational organizational chart developed for the program from a QA perspective. Describe the tasks in terms of QA activities associated with the project. Identify responsibilities for project tasks. Describe the procedures that link the QA process with the Systems Development, CM, and Test and Evaluation (T & E) functions.

19.2.1. CustomerDescribe the partnership activities performed by QA in support of contract performance.



QPM #

AQS 200-001-WI

Revision

1


19.2.2. System DevelopmentDescribe the objectives of QA in monitoring formal development to ensure that the concepts and standards applied by QA are implemented at the project and program levels. Direct detail level work in support of tasks toward the individual processes within the SDLC.

19.2.3. Test and EvaluationDescribe the role of QA in ensuring that project requirements are satisfied and that formal testing is completed in accordance with plans, standards, and procedures. Discuss reviews of test plans, test specifications, test procedures, and test reports.

19.2.4. Configuration ManagementDescribe the role of QA in ensuring that CM activities are performed in accordance with the CM plans, standards, and procedures. Discuss reviews to verify that baseline control, configuration identification, configuration control, configuration status accounting, and configuration authentication have been accomplished.

19.2.5. QA Roles and ResponsibilitiesDescribe the organizational and functional alignment of the QA staff. Describe the roles and responsibilities at the management, team leader, and specialist levels.

19.3. PROCESSESProvide an overview of the processes that QA uses to ensure that processes and products associated with hardware, software, and documentation are monitored, sampled, and audited to ensure compliance with methodology, policy, and standards.

19.3.1. GeneralDescribe QA's role in performing reviews and audits associated with deliverables and with collections of deliverables making up an SDLC phase.

19.3.2. Peer ReviewCommit to QA participation in the peer review process to identify, document, measure, and eliminate defects in a work product.

19.3.3. Process ReviewDescribe audit and assessment reviews that ensure that appropriate steps are taken to carry out activities specified by the SDLC. Describe methods by which QA monitors processes by comparing the actual steps carried out with those in the documented procedures. Discuss QA's responsibility to provide review data to management to provide an indication of the quality and status of the project.

19.4. PROBLEM REPORTING AND CORRECTIVE ACTIONDescribe the role of QA in identifying problems and recommending corrective actions. Identify the requirement for tasks to include QA in problem reporting and corrective action functions. Discuss the procedures and formats for the preparation, tracking, and management involvement in the use of Quality Action Reports (QARs) used in the program.



QPM #

AQS 200-001-WI

Revision

1


19.4.1. Quality Action ReportsDescribe preparation of QARs to document anomalies, violations of program standards, or potential problems as identified during any point in the SDLC.

19.4.2. QA Escalation ProceduresDescribe the QA escalation procedures that bring high-risk or long-standing, unresolved noncompliance tracking issues to senior management's attention.

19.4.3. QA Report FormatsDescribe the report formats that formally document and transmit information from QA audits and/or assessment reviews.

19.5. TOOLS, TECHNIQUES, AND METHODOLOGIESIdentify the tools, techniques, and methodologies used to support the QA function. Discuss the application of these items to QA's function in appraisal, preventive (identification of nonconformance), and corrective actions that contribute to the success of the project.

19.5.1. SDLCDescribe QA's use of the SDLC, the supporting policies, and accepted standards in management of internal activities. Also describe the role of QA to ensure that any contractors conform to the requirements of the methodology, policies, and standards.

19.5.2. PoliciesDescribe QA's role in developing policy statements that expand, enhance, or clarify SDLC requirements, or that introduce new or enhanced standards.

19.5.3. StandardsDescribe requirement of QA to ensure that standards are identified that establishes the prescribed methods for development of work products. Also discuss QA's role in assessing standards for adequacy and applicability.

19.5.4. ToolsDescribe the tool sets that QA employs in the conduct of administrative and technical functions.

19.6. QUALITY ASSURANCE PLAN OUTLINECover Page

Table of Contents

1. General

1.1 Purpose

1.2 Reference

1.3 Objective

1.4 Glossary



QPM #

AQS 200-001-WI

Revision

1


2. Description of the Organization

2.1 Organization Customer

2.2 System Development

2.3 Test and Evaluation

2.4 Configuration Management

2.5 Quality Assurance Roles and Responsibilities

3. Processes

3.1 General

3.2 Peer Review

3.3 Process Review

4. Problem Reporting and Corrective Action

4.1 Quality Action Reports

4.2 Quality Assurance Escalation Procedures

5. Tools, Techniques and Methodologies

5.1 System Development Life Cycle

5.2 Policies

5.3 Standards

5.4 Tools



QPM #

AQS 200-001-WI

Revision

1


20 CONCEPT OF OPERATIONS

The Automation Project Concept Paper (CONOPS) document is a high-level requirements document that provides a mechanism for users to describe their expectations of the system. The CONOPS is used as input to the development of formal testable system and software requirements specifications.

The objective of the CONOPS is to capture the results of the conceptual analysis process. During this process, the characteristics of the proposed system (from the user's perspective) and the operational environment in which it needs to function are identified. Both of these aspects, the system's functionality and its operational environment, are equally important.

A CONOPS normally has the following characteristics:

Describes the envisioned system Identifies the various classes of users Identifies the different modes of operation Clarifies vague and conflicting needs among users Prioritizes the desired and optional needs of the users Supports the decision-making process that determines whether a system should

be developed Serves as the basis for the Functional Requirements Document (FRD)

The outline of the Concept of Operations is shown at the end of this appendix. The following paragraphs identify the specific contents of each the subsections of the document. The format of this document and its contents are specified in the FAA IRM Order 1370.76A – Aircraft Certification Information Resource Management (IRM) Program

20.1. STATEMENT OF NEEDIndicate why this information, process, or procedure should be automated at the national level and what function it would fulfill.

20.2. ORGANIZATIONAL UNITS IMPACTED (CUSTOMERS)Customers are defined as end-users of the proposed system. Identify internal customers by type; e.g., engineers in ACOs, policy staffs, principal inspectors; also identify any external customers; e.g., flight standards, public.

20.3. WORK TO BE AUTOMATEDBriefly describe the major functions of the project. Please do not describe the automation process.

20.4. COSTS AND BENEFITSDescribe possible benefits of automating this information, procedure or process.



QPM #

AQS 200-001-WI

Revision

1


20.5. OPTIONS CONSIDEREDThis is optional. If you have ideas on how this could be automated, please include.

20.6. HOW THE FUNCTION IS CURRENTLY PERFORMEDThis is optional.

20.7. REQUESTER’S NAME, ROUTING SYMBOL AND POSITIONInclude the requester’s information.

20.8. CONCEPT PAPERCover Page

Table of Contents

1. Statement of Need

2. Organizational Units Impacted (Customers)

3. Work to be Automated

4. Costs and Benefits

5. Options Considered

6. How the Function is Currently Performed

7. Requester’s Name, Routing Symbol and Position



QPM #

AQS 200-001-WI

Revision

1


21 SYSTEM SECURITY PLAN

Reference the NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems, dated November 1998.



QPM #

AQS 200-001-WI

Revision

1


22 PROJECT MANAGEMENT PLAN

The Project Management Plan is prepared for all projects. It is one of several key project-planning documents that use a building-block approach to planning. It is a vehicle for documenting project scope, tasks, schedule, allocated resources, and interrelationships with other projects. It also provides details on the involved functional units, required job tasks, cost and schedule performance measurement, and milestone and review scheduling.

Revisions to the Project Management Plan occur at the end of each phase, and as information becomes available. Software tools designed for work breakdown structures (WBSs), Gantt charts, network diagrams, and activity detail reports are available and should be used to complete the project management plan. The size of the project management plan should be commensurate with the size and complexity of the systems development effort and should generally follow the outline attached.

22.1. INTRODUCTIONThis section is a description of the project management plan purpose and scope.

22.2. PROJECT DESCRIPTIONThis section provides a description of the project in as much detail as is required to understand the nature of the project. Identify the project name and code, state the project's objective(s), and give the date the plan was finalized in the Planning Phase.

22.3. PROJECT BACKGROUNDThis section describes why the project is important to the organization, its mission, and the capabilities the project will provide to the organization. Include any background or history that is important to understanding the project.

22.3.1. Project Development StrategyThis section provides an overview of the development strategy selected for the project. For example, this strategy might include prototyping the system, use of commercial off-the-shelf software, or conversion of an existing system from one hardware and software family to another.

22.3.2. Organization of the Project PlanThis section briefly describes the organization of the Project Management Plan.

22.4. POINTS OF CONTACTThis section identifies the key points of contact for the project management plan, including the System Proponent, IRM Manager, and Project Manager. Identify any additional points of contact.

22.5. PROJECT REFERENCESThis section is a bibliography of key project references and deliverables produced before this point. For example, these references might include cost-benefit analyses, existing



QPM #

AQS 200-001-WI

Revision

1


documentation describing internal processes, or existing documentation of the system if the project is a conversion.

22.6. GLOSSARYThis section provides a glossary of all terms and abbreviations used in the plan. If the glossary is several pages in length, include it as an appendix.

22.7. ORGANIZATION AND RESPONSIBILITIESThis section should include the various organizations and staff titles, roles, and responsibilities involved in the development project. Describe team structures, reporting responsibilities and relationships, and guidelines for status reporting internally within the Information Resources Management Office and externally for any contractor support. Also provide a roles and responsibilities matrix. Identify the following key organization components:

Organization sponsor for the project Manager responsible for the day-to-day administration of the project (if different

from the sponsor) Quality Assurance (QA) organization Configuration Management (CM) organization

22.8. PROJECT DESCRIPTION, SCHEDULE AND RESOURCESThis section lists all tasks/activities to be completed within each phase of the project. If possible, use diagrams and tables (automated tools) to list the tasks and show any possible relationships among them. Repeat any subsection for each known task within the project.

This section should provide a detailed description of each task and its schedule, budget, and management. Also include an estimate of each software development phase-related work effort and deliverables.

Note: The actual structure of this subsection may be organized as best suits the project. For example, suppose the project has activities in the Requirements Definition and Design Phases. Sections 3.1, Project Work Breakdown Structure, through 3.7, Risk Management, could be repeated for each of these phases; or Sections 3.1 through 3.7 could be listed once, and subsections within those sections could address the two phases separately.

22.8.1. Project Work Breakdown StructureThis section describes the WBSs required for the project. The WBS is a family-tree structure that relates to products produced and tasks performed at the various phases of the project life cycle. A WBS displays and defines the product(s) to be developed or produced and relates the elements of work (tasks) to be accomplished to each other and to the end product(s).

Typically, three levels of WBSs are developed during the system development process: Summary, Project, and Contract. A WBS Dictionary is also helpful for creating and recording the WBS elements.



QPM #

AQS 200-001-WI

Revision

1


22.8.1.1. Summary Work Breakdown Structure

This section describes the Summary WBS, a high-level WBS that covers the first three levels of the Project WBS. The Summary WBS is used for management presentations but is not used for detailed day-to-day project management. The structure of the Summary WBS may vary depending on the nature of the project.

22.8.1.2. Project Work Breakdown Structure

This section describes the Project WBS, the detailed WBS that is used for the day-to-day management of a project. The Project WBS includes all important products and work elements, or tasks, of the project, regardless of whether these tasks are performed by AVS personnel or by a contractor. The Project WBS may be modified, if necessary, during the life cycle. Work elements requiring more than 2 person weeks of calendar time should be subdivided until the largest bottom-level work element represents work that can be accomplished in an interval of at least 1 person week, but not more than 2 person weeks. This subdivision may appear to be arbitrary; however, the bottom-level work elements should focus on finite tasks performed by a single individual. When that is done, the application of standard productivity rates can generally predict the expected duration of the work element and eliminate wide variation in work element duration. For a software system development project, the structure of the Project WBS should also reflect the project life-cycle approach. The structure of the Project WBS may vary depending on the nature of the project and should be customized by the Project Manager to reflect the particular project and the particular path through the life cycle. For example, a full-scale initial information system development project and a software conversion process would be expected to have somewhat different WBSs.

22.8.1.3. Contract Work Breakdown Structure

This section describes the Contract WBS (CWBS), a further breakdown of the contract-specific WBS that covers the products and work elements, or tasks, from the Project WBS that will be performed by a contractor. In addition to items derived from the Project WBS, the CWBS includes contractor-specific items that may not be reflected in the Project WBS. Depending on the nature of the project, the contractor may be responsible for a given part of the project development activities (such as QA), for a specific part of the development life cycle (such as the Requirements Definition phase), or for the entire development process. A preliminary CWBS may be specified in the acquisition plan. The contract line items, configuration items, contract work statement tasks, contract specification, and contractor responses will typically be expressed in terms of the preliminary CWBS.

22.8.1.4. Work Breakdown Structure Dictionary

A WBS Dictionary provides detailed descriptions of each WBS element. Each WBS Dictionary entry should contain a title that is the same as the WBS element it amplifies; a narrative describing the work represented by the element; the effort required (in person hours); the most likely duration (in calendar days); and references to any special skills or resources required to accomplish the work. WBS Dictionary entries should be completed only for the lowest-level WBS elements. Create one or more WBS and a WBS dictionary and generate the output in the form of graphic charts.



QPM #

AQS 200-001-WI

Revision

1


22.8.2. Resource EstimatesThis section should estimate, for each WBS element, the total amount of human resource effort required, by resource category. Use available tools to estimate, store, and output resource requirements per WBS element to use in the next component of the project plan.

22.8.3. ScheduleThis section presents the project schedule.

Assumptions made about task duration, resource availability, milestones, constraints, and optimization criteria should be carefully documented.

Provide the schedule in the forms of Gantt charts, milestone tables, and deliverables and dates lists.

22.8.4. Resource Acquisition PlanThis section describes the addition (and eventual departure) of project resources via a Resource Acquisition Plan. Each type of resource should be considered in this Resource Acquisition Plan. The plan should specify the source of the resources, the numbers of each, the start date for each, and the duration needed. It also should consider additional, associated resource requirements, such as space, hardware and software, office equipment, other facilities, and tools.

22.8.5. Communication PlanThis section should discuss frequencies, target audiences, media, sources, formats, locations, forms, and types of information delivered in each form of communication. Careful thought should be given to satisfying existing standards and following existing conventions, and consideration should also be given to improving the communication process in general and to ensuring that communication is enabled and simplified for all project team members and external entities. Periodic status reports, newsletters, bulletins, problem reports, issues lists, status and review meetings, team meetings, and other forms of communication should all be carefully considered and documented when creating the communication plan. Output the communication plan in the form of a communication item/audience matrix.

22.8.6. Project Standards and ProceduresWhile the estimating and scheduling activities are going on, assign members of the planning team to identify and document standards and procedures for the project team. These standards and procedures may already be in place Agency-wide, but, if not, they should be discovered and/or determined now. These include technical standards, business-related standards, and QA standards. Technical standards and procedures include such things as naming conventions, walk-through requirements, CM rules, security standards, documentation requirements, tools, modeling techniques, and technical contractual obligations. Business-related standards and procedures include such things as procedures for scope changes, requirements changes, costing, earned value implementation, and sign-off standards. QA standards and procedures include such things as review processes, testing procedures, and defect tracking requirements. QA may also provide standards on the use of metrics.



QPM #

AQS 200-001-WI

Revision

1


22.8.7. Risk ManagementFor this section, refer to Section 17, Risk Management Plan, created during the System Concept Development Phase. Address approaches for mitigating the effects of these factors. Add subsections as necessary to separate different categories of risk or different risk-inducing factors.

22.9. SECURITY AND PRIVACYThis section should review security and privacy requirements for the project and should ensure that the Project Plan reflects these requirements.

22.9.1. Privacy IssuesThis section identifies privacy issues that should be addressed during the phases of the information system development effort and define the process to be established for addressing the privacy issues throughout the life cycle. It is important that there be a preliminary analysis of the potential privacy effects of the proposed information system. The purpose will be to establish for the project team and the review process an awareness of the privacy-related issues that will have to be addressed as the system is planned, developed, and implemented. The AVS Enterprise Architect should be consulted to check the architecture for documented privacy-related information objects.

22.9.2. Computer Security ActivitiesThis section reviews and evaluates requirements for security risk assessment and computer security planning to determine that all system vulnerabilities, threats, risks, and privacy issues will be identified and that an accurate determination will be made of the sensitivity of the system and information. Refer to Sections 4, System Concept Development Phase, 5, Requirements Definition Phase, and 6, Design Phase, for more information on security considerations.

22.10. PROJECT MANAGEMENT PLAN OUTLINECover Page

Table of Contents

1. Introduction

1.1 Project Description

1.2 Project Background

1.2.1 Project Description Strategy

1.2.2 Organization of the Project Plan

1.3 Points of Contact

1.4 Project References

1.5 Glossary

2. Organization and Responsibilities

3. Project Description, Schedule and ResourcesUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


3.1 Project Work Breakdown Structure

3.1.1 Summary Work Breakdown Structure

3.1.2 Project Work Breakdown Structure

3.1.3 Contract Work Breakdown Structure

3.1.4 Work Breakdown Structure Dictionary

3.2 Resource Estimates

3.3 Schedule

3.4 Resource Acquisition Plan

3.5 Communication Plan

3.6 Project Standards and Procedures

3.7 Risk Management

4. Security and Privacy

4.1 Privacy Issues

4.2 Computer Security Activities



QPM #

AQS 200-001-WI

Revision

1


23 VERIFICATION AND VALIDATION PLAN

This plan is from the FIPS PUB 101, June 1983, Guideline for Life cycle Validation, Verification, and Testing of Computer Software.

23.1. BACKGROUND AND INTRODUCTIONThis section establishes the context for the V&V document. It is brief and introductory in nature. It focuses on those aspects of the problem and/or solution that influence the V&V needs and approach.

23.1.1. Statement of ProblemDescribe the problem in concise terms.

23.1.2. Proposed SolutionDescribe the proposed solution that influences the V&V needs and approach.

23.1.3. References and Related DocumentsList all documents referenced in the plan or that impact the V&V effort. For selected significant documents, briefly describe how the referenced document impacts the V&V effort.

23.2. V&V REQUIREMENTS AND MEASUREMENT CRITERIAThis section presents the V&V requirements in one of several formats: the total V&V requirements, with all worksheets and phase information; a summary of requirements information; and a statement of project level information, with phase data presented later.

23.2.1. V&V Requirements and their ImportanceBriefly describe the functional, performance, reliability or other requirements and why they are important to this system or subsystem.

23.2.2. Measurement Criteria for Each RequirementBriefly describe general, product specific or phase specific measurement criteria for the above requirements.

23.2.3. References and Related DocumentsList any documents that the above might be referenced in (if a large document). These could be the SBD, CBA, Feasibility Study, etc.

23.3. PHASE BY PHASE V&V PLANSFirst, describe the V&V approach by phases, products, major reviews and checkpoints, and practices common to all phases. Then present the specific activities to be carried out phase by phase.

23.3.1. Project Background and Summary InformationProject Phases and products



QPM #

AQS 200-001-WI

Revision

1


Major reviews (both management and technical)

23.3.2. Planning phase V&V ActivitiesFor each phase, list the following information.

V&V activities V&V techniques and tools selected Reviews Methods of analysis Required support tools, automated & other Roles and responsibilities Schedules Budgets Personnel

23.3.3. Requirements Analysis Phase

23.3.4. Design Phase

23.3.5. Development Phase

23.3.6. Integration and Test Phase

23.3.7. Implementation Phase

23.3.8. Operations and Maintenance Phase

Appendix A Project and Environmental Considerations

Appendix B Technique and Tool Selection Information

23.4. VERIFICATION AND VALIDATION PLAN OUTLINECover Page

Table of Contents

1.0 Background and Introduction

1.1 Statement of Problem



QPM #

AQS 200-001-WI

Revision

1


1.2 Proposed Solution

1.3 References/Related Documents

2.0 V&V Requirements and Measurement Criteria

2.1 V&V Requirements and Their Importance

2.2 Measurement Criteria for Each Requirement

2.3 References/Related Documents

3.0 Phase by Phase V&V Plans

3.1 Project Background and Summary Information

3.2 Planning Phase V&V Activities

3.3 Requirements Analysis Phase

3.4 Design Phase

3.5 Development Phase

3.6 Integration and Test Phase

3.7 Implementation Phase

3.8 Operations and Maintenance Phase

Appendix A Project and Environment Considerations

A. Technical Issues

B. Project Constraints

C. Computing Resources

Appendix B Technique and Tool Selection Information

A. Candidate list of techniques and tools

B. Rationale for selection of techniques and tools



QPM #

AQS 200-001-WI

Revision

1


24 SYSTEMS ENGINEERING MANAGEMENT PLAN

The following sections should be considered for inclusion in the SEMP. Additionally, if both a government and a contractor SEMP are needed, the contents should be coordinated and integrated such that the technical management plans for the project are unambiguous to all concerned.

24.1. INTRODUCTIONThis section identifies the project, the applicable organization (contractor, government, or both), the date approved, and the revision version. If applicable, the title page should show an internal document control number.

24.1.1. Executive SummaryThis section describes the technical plan summary and applicability. If applicable, it also lists major subordinate plans.

24.1.2. Table of Contents

24.1.3. Project SummaryBriefly describe the project, to include complexities and challenges that are addressed by the technical development effort.

24.1.4. ScopeDescribe the applicability of the SEMP and assign general responsibilities for the required activities shown in the SEMP.

24.1.5. Applicable DocumentsList by title, version number, and issue date applicable documents to the technical management efforts described in the SEMP.

24.2. SYSTEM ENGINEERING PROCESSThis section describes the system engineering process to be applied to the project and assigns specific organizational responsibilities for the technical effort, to include contracted or subcontracted technical tasks. This section also details or references technical processes and procedures to be applied to the effort. Where these processes or procedures are developed as part of the project, the need dates and development schedule should be shown.

24.2.1. Systems Engineering Process PlanningThis section addresses planning for the key system outputs, to include products, processes, and trained people. The following may be included in this section:

Major products. Include major specification and product baseline development and control

System engineering process inputs. Include major requirements documents and resolution instructions for conflicting requirements



QPM #

AQS 200-001-WI

Revision

1


Technical objectives. Include cost, schedule, and key performance objectives Technical work breakdown structure. Describe how and when the technical work

breakdown structure will be developed, to include development and tracking tool sets usage

Subcontracted technical efforts. Describe the integration of contracted and subcontracted technical efforts

Processes. Describe the use of established technical processes and standards on the project

Process development. Describe processes to be developed as part of the project, together with the schedule for their development

Constraints. List any significant constraint to the technical effort

24.2.2. Requirements AnalysisThis section describes the methods, procedures, and tools used to analyze project requirements. This section should specify specific tools to be used to capture and trace project requirements.

24.2.3. Functional analysis/allocationThis section addresses the methods and tools used analyze the project requirements and allocate them down into project component functional requirements.

24.2.4. SynthesisThis section addresses the methods and tools used to analyze the functional requirements and allocate those requirements to a physical project component.

24.2.5. System AnalysisThis section describes the processes and procedures to be used for formal and informal trade studies, to include system and cost-benefit effectiveness analyses. Also included in this section are the risk management approaches to be used on the project.

24.2.6. System ControlThis section describes the control strategies needed for the following:

Configuration management Data management Technical performance measurement Quality control Interface management Schedule tracking and control Formal technical reviews Informal technical reviews/interchanges Subcontractor/supplier control Requirements control



QPM #

AQS 200-001-WI

Revision

1


24.3. TECHNOLOGY REFRESHMENTThis section describes the plans to establish and maintain a viable technological baseline during project development. This section also describes the strategy to be used during development to ensure refreshment remains a viable option during future project operations.

24.4. IMPLEMENTATION PLANNINGThis section outlines the planned activities leading to project implementation. Included in this area may be plans for:

Test and evaluation Transition of technical baselines to operations and maintenance Supportability planning Facilities planning Operations and user training development Project integration into an existing system-of-systems architecture

24.5. SPECIALTY ENGINEERING PLANNINGThis section outlines any special subject applicable to the project not covered in a previous section.

24.6. SYSTEMS ENGINEERING MANAGEMENT PLAN OUTLINECover Page

Table of Contents

1. Introduction

1.1 Executive Summary

1.2 Project Summary

1.3 Scope

1.4 Applicable Documents

2. Systems Engineering Process

2.1 Systems Engineering Process Planning

2.2 Requirements Analysis

2.3 Functional Analysis/Allocation

2.4 Synthesis

2.5 Systems Analysis

2.6 Systems Control

3. Technology Refreshment

4. Implementation Planning



QPM #

AQS 200-001-WI

Revision

1


5. Specialty Engineering Planning



QPM #

AQS 200-001-WI

Revision

1


25 FUNCTIONAL REQUIREMENTS DOCUMENT

25.1. INTRODUCTIONThe functional requirements document (FRD) is a formal statement of an application's functional requirements. It serves the same purpose as a contract. The developers agree to provide the capabilities specified. The client agrees to find the product satisfactory if it provides the capabilities specified in the FRD.

Quality is meeting requirements. For that reason, the FRD is the central document in system development. It is used for the following:

Designing and developing the application system. Evaluating the product in all subsequent phases of the life cycle. Determining the success of the project.

The FRD has the following characteristics:

It demonstrates that the application provides value to AVS in terms of the business objectives and business processes in the 5-year plan.

It contains a complete set of requirements for the application. It leaves no room for anyone to assume anything not stated in the FRD.

It is solution independent. The FRD is a statement of what the application is to do-not of how it works. The FRD does not commit the developers to a design. For that reason, any reference to the use of a specific technology is entirely inappropriate in an FRD.

A requirement is a condition that the application must meet for the customer to find the application satisfactory. A requirement has the following characteristics:

It provides a benefit to the organization. That benefit is directly traceable to the business objectives and business processes stated in AVS or service-specific strategic guidance.

It describes the capabilities the application must provide in business terms.

It does not describe how the application provides that capability. It does not describe such design considerations as computer hardware,

operating system, and database design. It is stated in unambiguous words. Its meaning is clear and

understandable. It is verifiable.

25.1.1. Project DescriptionProvide a brief overview of the project.

25.1.1.1. Background

Summarize the conditions that created the need for the application.UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


25.1.1.2. Purpose

Describe the business objectives and business processes from the CONOPS document and the CBA that this application supports.

25.1.1.3. Assumptions and Constraints

Assumptions are future situations, beyond the control of the project, whose outcomes influence the success of a project. The following are examples of assumptions:

Availability of a hardware/software platform Pending legislation Court decisions that have not been rendered Developments in technology

Constraints are conditions outside the control of the project that limit the design alternatives. The following are examples of constraints:

Government regulations Standards imposed on the solution Strategic decisions

Be careful to distinguish constraints from preferences. Constraints exist because of real business conditions. Preferences are arbitrary. For example, a delivery date is a constraint only if there are real business consequences that can happen as a result of not meeting the date. For example, if failing to have the subject application operational by the specified date places AVS in legal default, the date is a constraint. A date chosen arbitrarily is a preference. Preferences, if included in the FRD, should be noted as such.

25.1.1.4. Interfaces to External Systems

Name the applications with which the subject application must interface. State the following for each such application:

Name of application Owner of application (if external to AVS) Details of interface (only if determined by the other application) Reference applicable Data Standards specific to the interface.

25.1.2. Points of ContactList the names, titles, and roles of the major participants in the project. At a minimum, list the following:

AVS project leader Development project leader User contacts AVS employee whose signature constitutes acceptance of the FRD



QPM #

AQS 200-001-WI

Revision

1


25.1.3. Document ReferencesName the documents that were sources of this version of the FRD. Include meeting summaries, white paper analyses, CONOPS, CBA, and other System Development Life Cycle deliverables, as well as any other documents that contributed to the FRD. Include the Configuration Management identifier and date published for each document listed.

25.2. FUNCTIONAL REQUIREMENTSThe functional requirements describe the core functionality of the application. This section includes the data and functional process requirements.

25.2.1. Data RequirementsDescribe the data requirements by producing a logical data model, which consists of entity relationship diagrams, entity definitions, and attribute definitions. This is called the application data model. The data requirements describe the business data needed by the application system. Data requirements do not describe the physical database.

25.2.2. Functional Process RequirementsProcess requirements describe what the application must do. Process requirements relate the entities and attributes from the data requirements to the users' needs.

State the functional process requirements in a manner that enables the reader to see broad concepts decomposed into layers of increasing detail.

Process requirements may be expressed using data flow diagrams, text, or any technique that provides the following information about the processes performed by the application:

Context Detailed view of the processes Data (attributes) input to and output from processes Logic used inside the processes to manipulate data Accesses to stored data Processes decomposed into finer levels of detail

25.3. OPERATIONAL REQUIREMENTSOperational requirements describe the non-business characteristics of an application.

State the requirements in this section. Do not state how these requirements will be satisfied. For example, in the Reliability section, answer the question, "How reliable must the system be?” Do not state what steps will be taken to provide reliability.

Distinguish preferences from requirements. Requirements are based on business needs. Preferences are not. If, for example, the user expresses a desire for sub-second response but does not have a business-related reason for needing it, that desire is a preference.



QPM #

AQS 200-001-WI

Revision

1


25.3.1. SecurityThe security Section describes the need to control access to the data. This includes controlling who may view and alter application data.

State the consequences of the following breaches of security in the subject application:

Erasure of contamination of application data Disclosure of Government secrets Disclosure of privileged information about individuals

State the type(s) of security required. Include the need for the following as appropriate:

State if there is a need to control access to the facility housing the application.

State the need to control access by class of users. For example, "No user may access any part of this application who does not have at least a (specified) clearance."

State the need to control access by data attributes. State, for example, if one group of users may view an attribute but may not update it while another type of user may update or view it.

State the need to control access based on system function. State for example, if there is a need to grant one type of user access to certain system functions but not to others. For example, "This function is available only to the system administrator."

State if there is a need for accreditation of the security measures adopted for this application. For example, C2 protection must be certified by an independent authorized organization.

25.3.2. Audit TrailList the activities that will be recorded in the application's audit trail. For each activity, list the data to be recorded.

25.3.3. Data CurrencyData currency is a measure of how recent data are. This section answers the question, "When the application responds to a request for data how current must those data be?" Answer that question for each type of data request.

25.3.4. ReliabilityReliability is the probability that the system will be able to process work correctly and completely without being aborted.

State the following in this section:

What damage can result from this system's failure? Loss of human life Complete or partial loss of the ability to perform a mission-critical function Loss of revenue

Loss of employee productivity What is the minimum acceptable level of reliability?



QPM #

AQS 200-001-WI

Revision

1


State required reliability in any of the following ways:

Mean Time Between Failure is the number of time units the system is operable before the first failure occurs.

Mean Time To Failure is computed as the number of time units before the system is operable divided by the number of failures during the time period.

Mean Time To Repair is computed as the number of time units required to perform system repair divided by the number of repairs during the time period.

25.3.5. RecoverabilityRecoverability is the ability to restore function and data in the event of a failure.

Answer the following questions in this section:

In the event the application is unavailable to users (down) because of a system failure, how soon after the failure is detected must function be restored?

In the event the database is corrupted, to what level of currency must it be restored? For example "The database must be capable of being restored to its condition on no more than one hour before the corruption occurred."

If the process site (hardware, data, and onsite backup) is destroyed how soon must the application be able to be restored?

25.3.6. System AvailabilitySystem availability is the time when the application must be available for use. Required system availability is used in determining when maintenance may be performed.

In this section state the hours (including time zone) during which the application is to be available to users. For example, "The application must be available to users Monday through Friday between the hours of 6:30 a.m. and 5:30 p.m. EST." If the application must be available to users in more than one time zone state the earliest start time and the latest stop time.

Include the times when usage is expected to be at its peak. These are times when system unavailability is least acceptable.

25.3.7. Fault ToleranceFault tolerance is the ability to remain partially operational during a failure. Describe the following in this section:

Which functions need not be available at all times? If a component fails what (if any) functions must the application continue to

provide? What level of performance degradation is acceptable?

For most applications, there are no fault tolerance requirements. When a portion of the application is unavailable there is no need to be able to use the remainder for the application.

25.3.8. PerformanceDescribe the requirements for the following:



QPM #

AQS 200-001-WI

Revision

1


Response time for queries and updates Throughput Expected volume of data Expected volume of user activity (for example, number of transactions per hour,

day, or month)

25.3.9. CapacityList the required capacities and expected volumes of data in business terms. For example, state the number of cases about which the application will have to store data. For example, "The project volume is 600 applications for naturalization per month." State capacities in terms of the business. Do not state capacities in terms of system memory requirements or disk space.

25.3.10. Data RetentionDescribe the length of time the data must be retained. For example, "information about an application for naturalization must be retained in immediately accessible from for three years after receipt of the application."

25.4. REQUIREMENTS TRACEABILITY MATRIXThe requirements traceability matrix (RTM) provides a method for tracking the functional requirements and their implementation through the development process. Each requirement is included in the matrix along with its associated section number. As the project progresses, the RTM is updated to reflect each requirement's status. When the product is ready for system testing, the matrix lists each requirement, what product component addresses it, and what test verifies that it is correctly implemented.

Include columns for each of the following in the RTM:

25.4.1. Requirement description25.4.2. Requirement reference in FRD25.4.3. Verification Method25.4.4. Requirement reference in Test Plan25.5. GLOSSARYInclude business terms peculiar to the application. Do not include any technology-related terms.

25.6. FUNCTIONAL REQUIREMENTS DOCUMENT OUTLINECover Page

Table of Contents

1.0 Introduction

1.1 Project Description

1.1.1 Background

1.1.2 PurposeUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


1.1.3 Assumptions and Constraints

1.1.4 Interfaces to External Systems


1.3 Document References

2.0 Functional Requirements

2.1 Data Requirements

2.2 Functional Process Requirements

3.0 Operational Requirements

3.1 Security

3.2 Audit Trail

3.3 Data Currency

3.4 Reliability

3.5 Recoverability

3.6 System Availability

3.7 Fault Tolerance

3.8 Performance

3.9 Capacity

3.10 Data Retention

4.0 Requirements Traceability Matrix

Glossary



QPM #

AQS 200-001-WI

Revision

1


26 TEST AND EVALUATION MASTER PLAN

26.1. INTRODUCTIONThe Test Plan identifies the tasks and activities to be performed to ensure that all aspects of the system are adequately tested and that the system can be successfully implemented. The Test Plan documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. The Test Plan describes the test activities of the subsystem Integration Test, the System Test, the User Acceptance Test, and the Security Test in progressively higher levels of detail as the system is developed.

The Test Plan provides guidance for the management of test activities, including organization, relationships, and responsibilities. The test case procedures may be included in the Test Plan or in a separate document, depending on system size. The users assist in developing the Test Plan, which describes the nature and extent of tests deemed necessary. This provides a basis for verification of test results and validation of the system. The validation process ensures that the system conforms to the functional requirements in the FRD and that other applications or subsystems are not adversely affected. A test analysis report is developed at each level of testing to record the results of testing and certify readiness for system implementation (see the Integration and Test Phase).

Problems, deficiencies, modifications, and refinements identified during testing or implementation should be tracked under configuration control and tested using the same test procedures as those described in the Test Plan. Specific tests may need to be added to the plan at that time, and other documentation may need updating upon implementation, Notification of implemented changes to the initiator of the change request/problem report and to the users of the system is also handled as part of the configuration control process.

26.2. PURPOSEIn this section, present a clear, concise statement of the purpose for the project Test Plan and identify the application system being tested by name. Include a summary of the functions of the system and the tests to be performed.

26.3. BACKGROUNDThis section should provide a brief description of the history and other background leading up to the system development process. Identify the user organization and the location where the testing will be performed. Describe any prior testing, and note results that may affect this testing.

26.4. SCOPEThis section describes the projected boundaries of the planned tests. Include a summary of any constraints imposed on the testing, whether they are because of a lack of specialized test equipment, or constraints on time or resources. Describe constraints in greater detail in Section 5.1, Limitations.



QPM #

AQS 200-001-WI

Revision

1


26.5. GLOSSARYThis section provides a list of all terms and abbreviations used in this document. If the list is several pages in length, it may be placed as an appendix.

26.6. LIMITATIONS AND TRACEABILITYThis section elaborates on the limitations summarized in Section 3, Scope, and cross-references the functional requirements and detailed specifications to the tests that demonstrate or partially demonstrate that capability.

26.6.1. LimitationsThis section describes limitations imposed on the testing, whether they are because of a lack of specialized test equipment, or constraints on time or resources. Indicate what steps, if any, are being taken to reduce program risk because of the test limitations(s).

26.6.2. TraceabilityThis section expands the traceability matrix created in the FRD by including test activities that address user requirements. The matrix begins with the user requirements and assists in tracing how the requirements are addressed in subsequent phases and documents, including the System Design Document and Test Plan. The matrix may be broken up into segments, if appropriate. For example, a separate matrix of test plan sections that reference particular sections in the system design document in the Design phase may be provided. The intent is to show that the test plan covers all functionality, performance, and other requirements associated with each design element (unit, module, subsystem, and system) in the system design document.

When a test supports a particular requirement, the relationship should be noted at their intersection in the matrix. The listed requirements may be explicitly stated or may be derived or implicit. All explicit requirements must be included. The granularity of the list should be detailed enough that each requirement is simple and testable.

26.7. TEST PLANSThis section describes the levels of tests that take place during development: integration, system security, and user acceptance tests, and the planning that is needed. The test environment is described in terms of milestones, schedules, and resources needed to support testing.

26.7.1. Test LevelsThis section should include a list of the types of software testing to be performed. List all applicable levels and enter "Not applicable" if a particular level of testing does not apply to the project.

26.7.1.1. Subsystem Integration Test

This section discusses the tests that examine the subsystems making up of integrated groupings of software units and modules. This is the first level of testing where problem reports are generated; these reports are classified by severity, and their resolution is monitored and reported. Subsystem integration test results (including the test data sets and outputs produced



QPM #

AQS 200-001-WI

Revision

1


from the tests) may be delivered as part of the final Test Plan, with the integration test analysis report or as an appendix.

26.7.1.2. System Test

This section describes the type of testing that determines system compliance with standards and satisfaction of functional and technical requirements when executed on target hardware using simulated operational data files and prepared test data. System documents and training manuals are examined for accuracy, validity, completeness, and usability. During this testing period, software performance, response time, and ability to operate under stressed conditions are tested. External system interfaces are also tested. All findings are recorded in a system test analysis report.

26.7.1.3. User Acceptance Test

This section describes the tests performed in a non-production environment that mirrors the environment in which the system will be fielded. Every system feature may be tested for correctness and satisfaction of functional requirements. System interoperability, all documentation, system reliability, and the level to which the system meets user requirements are evaluated. Performance tests may be executed to ensure that screen response time, program run time, operator intervention requirements, and reconciliation issues are addressed.

26.7.1.4. Security Test

This section describes the tests performed to determine if the system meets all of the security requirements listed in the FRD. Include internal controls or application security features mentioned in the context of security testing. Security testing is performed in the operational (production) environment under the guidance of the security staff.

26.7.2. Test Environment and SchedulesThis section provides a brief description of the inputs, outputs, and functions of the software being tested.

26.7.2.1. Software Description

This section lists the software being tested. Provide a description of the purpose of the software being tested, and any interfaces to subsystems or other components of the system.

26.7.2.2. Milestones

This section lists the milestone events and dates for the testing.

26.7.2.3. Organizations and Locations

This section provides information on the participating organizations and the location where the software will be tested.

26.7.2.4. Schedule

This section shows the detailed schedule of dates and events for the testing by location. Events should include familiarization, training, test data set generation, and collections, as well as the volume and frequency of the input for testing.



QPM #

AQS 200-001-WI

Revision

1


26.7.2.5. Resource Requirements

This section and associated statements define the resource requirements for the testing.

26.7.2.5.1. Equipment

This section shows the expected period of use, types, and quantities of equipment needed.

26.7.2.5.2. Software

This section lists other software needed to support testing that is not part of the software being tested. This should include debugging software and programming aids as well as many current programs to be run in parallel with the new software to ensure accuracy; any drivers or system software to be used in conjunction with the new software to ensure compatibility and integration; and any software required to operate the equipment and record test results.

26.7.2.5.3. Personnel

This section lists the number of, skill types of, and schedules for personnel - from the user, database, Quality Assurance, security, and development groups - who will be involved in the test. Include any special requirements, such as multiple-shift operation or key personnel.

26.7.2.6. Testing Material

This section describes the documents needed to perform the tests. It could include software, resources, data and other information.

26.7.2.7. Test Training

This section describes or references the plan for providing training in the use of the software being tested. Specify the types of training, personnel to be trained, and the training staff.

26.7.2.8. Test Methods and Evaluation

This section documents the test methodologies, conditions, test progression or sequencing, data recording, constraints, criteria, and data reduction.

26.7.2.8.1. Methodology

This section describes the general methodology or testing strategy for each type of testing described in this Test Plan.

26.7.2.8.2. Conditions

This section specifies the type of input to be used, such as real-time entered test data or canned data for batch runs. It describes the volume and frequency of the input, such as the number of transactions per second tested, etc. Sufficient volumes of test transactions should be used to simulate live stress testing and to incorporate a wide range of valid and invalid conditions. Data values used should simulate live data and also test limited conditions.



QPM #

AQS 200-001-WI

Revision

1


26.7.2.8.3. Test Progression

This section describes the manner in which progression is made from one test to another, so the entire cycle is completed.

26.7.2.8.4. Data Recording

This section describes the method used for recording test results and other information about the testing.

26.7.2.8.5. Constraints

This section indicates anticipated limitations on the test because of test conditions, such as interfaces, equipment, personnel, and databases.

26.7.2.8.6. Criteria

This section describes the rules to be used to evaluate test results, such as range of data values used, combinations of input types used, or maximum number or allowable interrupts or halts.

26.7.2.8.7. Data Reduction

This section describes the techniques that will be used for manipulating the test data into a form suitable for evaluation - such as manual or automated methods - to allow comparison of the results that should be produced to those that are produced.

26.8. TEST DESCRIPTIONThis section describes each test to be performed. Test at each level should include verification of access control and system standards, data security, functionality, and error processing. As various levels for testing (subsystem integration, system, user acceptance testing, and security) are completed and the test results are documented, revisions or increments for the Test Plan can be delivered. The subsections of this section should be repeated for each test within the project. If there are many tests, place them in an appendix.

26.8.1. Test NameThis section identifies the test to be performed for the named module, subsystem, or system and addresses the criteria discussed in the subsequent sections for each test.

26.8.1.1. Test Description

Describes the test to be performed. Tests at each level of testing should include those designed to verify data security, access control, and system standards; system/subsystem/unit functionality; and error processing as required.

26.8.1.2. Control

Describe the test control-such as manual, semiautomatic, or automatic insertion of inputs; sequencing of operations; and recording of results.



QPM #

AQS 200-001-WI

Revision

1


26.8.1.3. Inputs

Describe the data input commands used during the test. Provide examples of input data. At the discretion of the Project Manager, input data listings may also be requested in computer readable form for possible future use in regression testing.

26.8.1.4. Outputs

Describe the output data expected as a result of the test and any intermediate messages or display screens that may be produced.

26.8.1.5. Procedures

Specify the step-by-step procedures to accomplish the test. Include test setup, initialization steps, and termination. Also include effectiveness criteria or pass criteria for each test procedure.

26.9. TEST AND EVALUATION MASTER PLAN OUTLINECover Page

Table of Contents

1.0 Purpose

2.0 Background

3.0 Scope

4.0 Glossary

5.0 Limitations and Traceability

5.1 Limitations

5.2 Traceability (Functional Requirements Traceability Matrix)

6.0 Test Plan

6.1 Test Levels

6.1.1 Subsystem Integration Test

6.1.2 System Test

6.1.3 User Acceptance Test

6.1.4 Security Test

6.2 Test Environment and Schedules

6.2.1 Software Description

6.2.2 Milestones

6.2.3 Organizations and Locations

6.2.4 Schedule

6.2.5 Resource RequirementsUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


6.2.5.1 Equipment

6.2.5.2 Software

6.2.5.3 Personnel

6.2.6 Testing Material

6.2.7 Test Training

6.2.8 Test Methods and Evaluation

6.2.8.1 Methodology

6.2.8.2 Conditions

6.2.8.3 Test Progression

6.2.8.4 Data Recording

6.2.8.5 Constraints

6.2.8.6 Criteria

6.2.8.7 Data Reduction

7.0 Test Descriptions

7.1 Test Name (repeat for each test)

7.1.1 Test Description

7.1.2 Control

7.1.3 Inputs

7.1.4 Outputs

7.1.5 Procedures



QPM #

AQS 200-001-WI

Revision

1


27 INTERFACE CONTROL DOCUMENT

27.1. SCOPEThis document provides an outline for use in the specification of requirements imposed on one or more system, subsystems, Hardware Configuration Items (HCIs) Computer Software Configuration Items (CSCIs), manual operations, or other system components to achieve one or more interfaces among these entities. The Interface Control Document (ICD) created using this template will define one or more interfaces between two systems.

Overall, an ICD can cover requirements for any number of interfaces to a system.

Note: If there are multiple interfaces, they can be listed in a single ICD or multiple ICDs as needed. For example: System 1 has an interface with System 2 and System 3, multiple ICDs can be written describing System 1 to System 2; System 1 to System 3 - or - a single ICD can include both. In this latter case, each section in this template would be repeated to describe each interface.

Sample wording follows:

This Interface Control Document (ICD) specifies the interface(s) between System 1 and System 2, up through System N. Upon formal approval by the IRM Manager responsible for each participating system, this ICD shall be incorporated into the requirements baseline for each system.

27.2. SYSTEM IDENTIFICATIONThe following subsections shall contain a full identification of the systems participating in the interface, the contractors who are developing the systems, the interfacing entities, and the interfaces to which this document applies, including, as applicable, identification numbers(s), title(s), abbreviation(s), version number(s), release number(s), or any lower level version descriptors used. A separate paragraph should be included for each system that comprises the interface.

27.2.1. System 1The information provided in this paragraph should be sufficiently detailed so as to definitively identify the systems participating in the interface, the contractors developing/maintaining the systems, and the IRM Manager.

27.2.2. System 2The information provided should be similar to that provided in Section 1.1.1

27.3. DOCUMENT OVERVIEWSample wording follows:

The purpose of the ICD is to specify interface requirements to be met by the participating systems. It describes the concept of operations for the interface, defines the message structure and protocols which govern the interchange of data, and identifies the communication paths along which the data is expected to flow. The document is organized as:



QPM #

AQS 200-001-WI

Revision

1


Section 1.0 Scope of the Document Section 2.0 Concept of Operations Section 3.0 Detailed Interface Requirements Section 4.0 Qualification Methods Section 5.0 Notes Section 6.0 Appendices

27.4. APPLICABLE DOCUMENTSThis section shall list the number, title, revision, and date of all documents referenced or used in the preparation of this document. Document types included would be standards, Government documents, and other documents. This section shall also identify the source for all documents not available through AVS.

27.5. DESCRIPTIONProvide a description of the interface between <System1> and <System 2>.

27.5.1. System OverviewThis section should illustrate the interface and the data exchanged between the interfaces. Further information on the functionality and architecture of the participating systems is given the subsequent sections. In particular, each system should be briefly summarized with special emphasis on the functionality related to the interface. The hardware and software components of each system are also identified.

27.5.1.1. Interface Overview

Describe the functionality and architecture of the interfacing system as it relates to the proposed interface. Briefly summarize the system, placing special emphasis on functionality, including identification of key hardware and software components, as they relate to the interface. If more than one external system is to be part of the interface being defined, then include additional sections at this level for each additional external system.

27.5.2. Functional AllocationBriefly describe what operations are performed on each system involved in the interface and how the end users will interact with the interface being defined. If the end user does not interact directly with the interface being defined, describe the events that trigger the movement of information using the interface being defined.

27.5.3. Data TransferBriefly describe how data will be moved among component systems of the interface being defined. Include descriptions and diagrams of how connectivity among the systems will be implemented and of the type of messaging or packaging of data that will be used to transfer data among the systems. If more than one interface between these two systems is defined by this ICD, each should be identified in this section. A separate subsection (2.4.1, 2.4.2 etc.) may be included for each interface.



QPM #

AQS 200-001-WI

Revision

1


This ICD template will be primarily used for specification of interfaces that move information between two systems. Where an interface contains physical requirements that are imposed upon one or both of the interfacing systems, these physical requirements should be described in Section 2.4, and defined in Section 3.1.5, Physical Requirements. If an interface has no physical requirements, then so state.

27.5.4. TransactionsBriefly describe the types of transactions that will be utilized to move data among the component systems of the interface being defined. If multiple types of transactions will be utilized for different portions of the interface, a separate section may be included for each interface.

27.5.5. Security and IntegrityIf the interface defined has security and integrity requirements, briefly describe how access security will be implemented and how data transmission security will be implemented for the interface being defined. Include a description of the transmission medium to be used and whether it is a public or a secure line. Include a brief description of how data will be protected during transmission and how data integrity will be guaranteed. Include a description of how the two systems can be certain that they are communicating with each other and not with another system masquerading as one of them. Describe how an individual on one system can be audited and held accountable for resulting actions on the other component of the interface. Normally, this section should be an overview of how security and integrity will be implemented; Section 3.1.4 contains a detailed description of specified requirements.

An interface that is completely self-contained, such as movement of data between systems resident in the same computer room, may not have any security requirements. In this case, it should be so stated with an explanation of why the interface has no security and integrity requirements.

27.6. DETAILED INTERFACE REQUIREMENTSThis section specifies the requirements for one or more interfaces between two systems. This includes explicit definitions of the content and format of every message or file that may pass between the two systems and the conditions under which each message or file is to be sent. If an interface between the two systems is to be implemented incrementally, identify the implementation phase in which each message will be available. The structure in paragraph 3.1 should be replicated for each interface between the two participating systems.

The template contained in Section 3.1 including subsections, provides a generic approach to interface requirements definition. The specific interface definition should include only subsections relevant to the interface being defined and considerable liberty may be taken in the organization of Section 3.1 subsections. Where types of information not specified in Section 3.1 are required to clearly define the interface, additional subsections should be added. Other readily available documents (such as data dictionaries, standards for communication protocols, and standards for user interfaces) may reference in place of stating the information here. It may useful to include copies of such documents as attachments to the ICD. Where possible, the use of tables and figures is encouraged to enhance the understandability of the interface definition.



QPM #

AQS 200-001-WI

Revision

1


In defining interface requirements, clearly state which of the interfacing systems the requirement is being imposed upon.

Note: For ease of updates and understanding systems with multiple interfaces, this section may be included as an Appendix to the ICD rather than as a section of the ICD.

27.6.1. Interface 1 RequirementsBriefly summarize the interface. Indicate what data protocol, communication methods and processing priority is used by the interface. Data protocols used may include messages and custom ASCII files. Communication methods may include electronic networks or magnetic media. Indicate processing priority if information is required to be formatted and communicated as the data is created, as a batch of data is created by operator action, or in accordance with some periodic schedule. Requirements for specific messages or files to be delivered within a set interval of time should be included in Paragraphs 3.1.1 or 3.1.2.

27.6.1.1. Interface Processing Time Requirements

If information is required to be formatted and communicated as the data is created, as a batch of data is created by operator action, or in accordance with some periodic schedule, indicate processing priority. Requirements for specific messages or files to be delivered to the communication medium within a set interval of time should be included in Subsection 3.1.2. State the priority that the interfacing entities must assign to the interface. Priority may be stated as performance or response time requirements defining how quickly incoming traffic or data requests must be processed by the interfacing system to meet the requirements of the interface. Considerable latitude should be given in defining performance requirements to account for differences in hardware and transaction volumes at different installation sites of the interfacing systems. Response time requirements, which are impacted by resources and beyond the control of the interfacing systems (i.e., communication networks), are beyond the scope of an ICD.

27.6.1.2. Message (or File) Requirements

This subsection specifies the requirements for one or more interfaces between two systems. This includes explicit definitions of and the conditions under which each message is to be sent. The definition, characteristics and attributes of the command are described.

27.6.1.2.1. Data Assembly Characteristics

Use the following paragraphs to define the content and format of every message, file, or other data element assembly (records, arrays, displays, reports, etc.) Specified in Paragraph 3.1.2. In defining interfaces where data is moved among systems, define the packaging of data to be utilized. The origin, structure, and processing of such packets will be dependent on the techniques used to implement the interface. Define required characteristics of data element assemblies that the interfacing entities must provide, store, send, access, receive, etc.

When relevant to the packaging technique used, the following information should be provided:

Names/identifiers Project-unique identifier



QPM #

AQS 200-001-WI

Revision

1


Non-technical (natural language) name Technical name (e.g., record or data structure name in code or database) Abbreviations or synonymous names Structure of data element assembly Visual and auditory characteristics of displays and other outputs (such as colors,

layouts, fonts, icons and other display elements, beeps, lights) where relevant Relationships among different types of data element assemblies used for the

interface Priority, timing, frequency, volume, sequencing, and other constraints, such as

whether the assembly may be updated and whether business rules apply Sources (setting/sending entities) and recipients (using/receiving entities)

27.6.1.2.2. Field/Element Definition

Define the characteristics of individual data elements that comprise the data packets defined in Section 3.1.2.1. Sections 3.1.2.1 and 3.1.2.2 may be combined into one section in which the data packets and their component data elements are defined in a single table. Data element definitions should include only features relevant to the interface being defined and may include such features as:

Names/identifiers Project-unique identifier Priority, timing, frequency, volume, sequencing, and other constraints, such as

whether the data element may be updated and whether business rules apply AVS standard data element name Non-technical (natural-language) name Technical name (e.g. variable or field name in code or database) Abbreviation or synonymous names Data type (alphanumeric, integer, etc.) Size and format (such as length and punctuation of a character string) Units of measurement (such as meters, dollars, nanoseconds) Range or enumeration of possible values (such as 0-99) Accuracy (how correct) and precision (number of significant digits) Security and privacy constraints Sources (setting/sending entitles) and recipients (using/receiving entities)

27.6.1.3. Communication Methods

Communication requirements include all aspects of the presentation, session, network and data layers of the communication stack to which both systems participating in the interface must conform. The following subsections should be included in this discussion as appropriate to the interface being defined and may be supplemented by additional information as appropriate.



QPM #

AQS 200-001-WI

Revision

1


27.6.1.3.1. Interface Initiation

Define the sequence of events by which the connections between the participating systems will be initiated. Include the minimum and maximum number of connections that may be supported by the interface. Also include availability requirements for the interface (e.g., 24 hours a day, 7 days a week) that are dependent on the interfacing systems. Availability requirements beyond the control of the interfacing systems, such as network availability, are beyond the scope of an ICD.

27.6.1.3.2. Flow Control

Specify the sequence numbering, legality checks, error control and recovery procedures that will be used to manage the interface. Include any acknowledgment (ACK/NAK) messages related to these procedures.

27.6.1.4. Security Requirements

Specify the security features that required to be implemented within the message or file structure or in the communications processes. Define the Security required of the communication methods used (include safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing). For interactive interfaces, security features may include identification, authentication, encryption and auditing. Simple message broadcast or ASCII file transfer interfaces are likely to rely on features provided by communication services. Do not specify the requirements for features that are not provided by the systems to which the ICD applies. If the interface relies solely on physical security, or on the security of the networks and firewalls through which the systems are connected, so state.

27.6.2. Interface 2 RequirementsWhen more than one interface between two systems is being defined in a single ICD, each should be defined separately, including all of the characteristics described in Section 3.1 for each. There is no limit on the number of unique interfaces that can be defined in a single Interface Control Document. In general, all interfaces defined should involve the same two systems.

27.7. QUALIFICATION METHODSThis section defines a set of qualification methods to be used to verify that the requirements for the interfaces defined in Section 3 have been met. Qualification methods include:

Demonstration: The operation of interfacing entities that relies on observable functional operation not requiring the use of instrumentation, special test equipment, or subsequent analysis.

Test: The operation of interfacing entities using instrumentation or special test equipment to collect data for later analysis.

Analysis: The processing of accumulated data obtained from other qualification methods. Examples are reduction, interpretation, or extrapolation of test results.

Inspection: The visual examination of interfacing entities, documentation, etc.



QPM #

AQS 200-001-WI

Revision

1


Special qualification methods: Any special qualification methods for the interfacing entities, such as special tools, techniques, procedures, facilities, and acceptance limits.

27.8. NOTESThis section contains any general information that aids in understanding the document (e.g., background information, glossary).

27.9. APPENDICESAppendices may be used to provide information published separately for convenience in document maintenance (e.g., acronyms, abbreviations).

27.10. APPROVALSA page shall be included in the Interface Control Document (ICD) for signature of those individuals who have agreed to the interface defined in the ICD. At a minimum, the signatures of the IRM Managers for the two systems that will be interfacing are required. Sample wording and suggestions or other sign-offs that may be included follow:

Use this format for approvals for the Interface Control Document for Interfaces between System 1 and System 2, Version Number.

System 1 IRM Manager ______________________________ Date_____________

Printed name and title _______________________________________________

System 2 IRM Manager ______________________________ Date_____________


System 1 Configuration Control Board ______________________Date_____________


System 2 Configuration Control Board ______________________Date_____________


27.11. RECORD OF CHANGESThis record is maintained throughout the life of the document and summarizes the changes between approved versions of this document. Each new version of the document submitted for approval receives a sequential venison number. For instance, the first version of the document will be revision number 1.0. The old paragraph will designate the paragraph number and title where the information existed in the previous document if applicable. The revision comments will contain an explanation of the changes made and any new paragraph number and title if needed.

27.12. INTERFACE CONTROL DOCUMENT OUTLINE1.0 Scope

1.1 System Identification



QPM #

AQS 200-001-WI

Revision

1


1.1.1 System

1.1.2 System

1.2 Document Overview

1.3 Applicable Documents

2.0 Concept of Operations

2.1 System Overviews

2.11 Interface Overview

2.2 Year 2000 Compatibility

2.3 Functional Allocation

2.4 Data Transfer

2.5 Transactions

2.6 Security and Integrity

3.0 Detailed Interface Requirements

3.1 Interface 1 Requirements

3.1.1 Interface Processing Time Requirements

3.1.2 Message (or File) Requirements

3.1.3 Communication Methods

3.1.4 Security Requirements

3.2 Interface 2 Requirements

4.0 Qualification Methods

5.0 Notes

6.0 Appendices

7.0 Approvals

8.0 Record of Changes



QPM #

AQS 200-001-WI

Revision

1


28 SECURITY RISK ASSESSMENT

Reference the NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems, dated 2001.



QPM #

AQS 200-001-WI

Revision

1


29 CONTINGENCY PLAN

Reference the NIST Special Publication 800-34, Contingency Planning Guide for Information Technology Systems, dated June 2002.



QPM #

AQS 200-001-WI

Revision

1


30 CONVERSION PLAN

The Conversion Plan describes the strategies involved in converting data from an existing system to another hardware or software environment. It is appropriate to reexamine the original system's functional requirements for the condition of the system before conversion to determine if the original requirements are still valid. An outline of the Conversion Plan is shown below.

30.1. INTRODUCTIONThis section provides a brief description of introductory material.

30.1.1. Purpose and ScopeThis section describes the purpose and scope of the Conversion Plan. Reference the information system name and provide identifying information about the system undergoing conversion.

30.1.2. Points of ContactThis section identifies the System Proponent. Provide the name of the responsible organization and staff (and alternates, if appropriate) who serve as points of contact for the system conversion. Include telephone numbers of key staff and organizations.

30.1.3. Project ReferencesThis section provides a bibliography of key project references and deliverables that have been produced before this point in the project development. These documents may have been produced in a previous development life cycle that resulted in the initial version of the system undergoing conversion or may have been produced in the current conversion effort as appropriate.

30.1.4. GlossaryThis section contains a glossary of all terms and abbreviations used in the plan. If it is several pages in length, it may be placed in an appendix.

30.2. CONVERSION OVERVIEWThis section provides an overview of the aspects of the conversion effort, which are discussed in the subsequent sections.

30.2.1. System OverviewThis section provides an overview of the system undergoing conversion. The general nature or type of system should be described, including a brief overview of the processes the system is intended to support. If the system is a database or an information system, also include a general discussion of the type of data maintained, the operational sources, and the uses of those data.

30.2.2. System Conversion OverviewThis section provides an overview of the planned conversion effort.



QPM #

AQS 200-001-WI

Revision

1


30.2.2.1. Conversion Description

This section provides a description of the system structure and major components. If only selected parts of the system will undergo conversion, identify which components will and will not be converted.

If the conversion process will be organized into discrete phases, this section should identify which components will undergo conversion in each phase. Include hardware, software, and data as appropriate. Charts, diagrams, and graphics may be included as necessary. Develop and continuously update a milestone chart for the conversion process.

30.2.2.2. Type of Conversion

This section describes the type of conversion effort. The software part of the conversion effort usually falls into one of the following categories:

Intra-language conversion is a conversion between different versions of the same computer language or different versions of a software system, such as a database management system (DBMS), operating system, or local area network (LAN) management system.

Inter-language conversion is the conversion from one computer language to another or from one software system to another.

Same compiler conversions use the same language and compiler versions. Typically, these conversions are performed to make programs conform to standards, improve program performance, convert to a new system concept, etc. These conversions may require some program redesign and generally require some reprogramming.

In addition to the three categories of conversions described above, other types of conversions may be defined as necessary.

30.2.2.3. Conversion Strategy

This section describes the strategies for conversion of system hardware, software, and data.

30.2.2.3.1. Hardware Conversion Strategy

This section describes the strategy to be used for the conversion of system hardware, if any. Describe the new (target) hardware environment, if appropriate.

30.2.2.3.2. Software Conversion Strategy

This section describes the conversion strategy to be used for software.

30.2.2.3.3. Data Conversion Strategy

This section describes the data conversion strategy, data quality assurance, and the data conversion controls.

30.2.2.3.4. Data Conversion Approach

This section describes the specific data preparation requirements and the data that must be available for the system conversion. If data will be transported from the original system, provide



QPM #

AQS 200-001-WI

Revision

1


a detailed description of the data handling, conversion, and loading procedures. If these data will be transported using machine-readable media, describe the characteristics of those media.

30.2.2.3.5. Interfaces

In the case of a hardware platform conversion--such as mainframe to client/server--the interfaces to other systems may need reengineering. This section describes the affected interfaces and the revisions required in each.

30.2.2.3.6. Data Quality Assurance and Control

This section describes the strategy to be used to ensure data quality before and after all data conversions. This section also describes the approach to data scrubbing and quality assessment of data before they are moved to the new or converted system. The strategy and approach may be described in a formal transition plan or a document if more appropriate.

30.2.2.4. Conversion Risk Factors

This section describes the major risk factors in the conversion effort and strategies for their control or reduction. Descriptions of the risk factors that could affect the conversion feasibility, the technical performance of the converted system, the conversion schedule, or costs should be included. In addition, a review should be made to ensure that the current backup and recovery procedures are adequate as well as operational.

30.2.3. Conversion TasksThis section describes the major tasks associated with the conversion, including planning and pre-conversion tasks.

30.2.3.1. Conversion Planning

This section describes planning for the conversion effort. If planning and related issues have been addressed in other life-cycle documents, reference those documents in this section. The following list provides some examples of conversion planning issues that could be addressed:

Analysis of the workload projected for the target conversion environment to ensure that the projected environment can adequately handle that workload and meet performance and capacity requirements

Projection of the growth rate of the data processing needs in the target environment to ensure that the system can handle the projected near-term growth, and that it has the expansion capacity for future needs

Analysis to identify missing features in the new (target) hardware and software environment that were supported in the original hardware and software and used in the original system

Development of a strategy for recoding, reprogramming, or redesigning the components of the system that used hardware and software features not supported in the new (target) hardware and software environment but used in the original system



QPM #

AQS 200-001-WI

Revision

1


30.2.3.2. Pre-Conversion Tasks

This section describes all tasks that are logically separate from the conversion effort itself but that must be completed before the initiation, development, or completion of the conversion effort. Examples of such pre-conversion tasks include:

Finalize decisions regarding the type of conversion to be pursued.

Install changes to the system hardware, such as a new computer or communications hardware, if necessary.

Implement changes to the computer operating system or operating system components, such as the installation of a new LAN operating system or a new windowing system.

Acquire and install other software for the new environment, such a new DBMS or document imaging system.

30.2.3.3. Major Tasks and Procedures

This section addresses the major tasks associated with the conversion and the procedures associated with those tasks.

30.2.3.3.1. Major Task Name

Provide a name for each major task. Provide a brief description of each major task required for the conversion of the system, including the tasks required to perform the conversion, preparation of data, and testing of the system. If some of these tasks are described in other life-cycle documents, reference those documents in this section.

30.2.3.3.2. Procedures

This section should describe the procedural approach for each major task. Provide as much detail as necessary to describe these procedures.

30.2.4. Conversion ScheduleThis section provides a schedule of activities to be accomplished during the conversion. Pre-conversion tasks and major tasks for all hardware, software, and data conversions described in Section 2.3, Conversion Tasks, should be described here and should show the beginning and end dates of each task. Charts may be used as appropriate.

30.2.5. SecurityIf appropriate for the system to be implemented, provide an overview of the system security features and the security during conversion.

30.2.5.1. System Security Feature

The description of the system security features, if provided, should contain a brief overview and discussion of the security features that will be associated with the system when it is converted. Reference other life-cycle documents as appropriate. Describe the changes in the security features or performance of the system that would result from the conversion.



QPM #

AQS 200-001-WI

Revision

1


30.2.5.2. Security during Conversion

This section addresses security issues specifically related to the conversion effort.

30.3. CONVERSION SUPPORTThis section describes the support necessary to implement the system. If there are additional support requirements not covered by the categories shown here, add other subsections as needed.

30.3.1. HardwareThis section lists support equipment, including all hardware to be used for the conversion.

30.3.2. SoftwareThis section lists the software and databases required to support the conversion. It describes all software tools used to support the conversion effort, including the following types of software tools, if used:

Automated conversion tools, such as software translation tools for translating among different computer languages or translating within software families (such as, between release versions of compilers and DBMSs)

Automated data conversion tools for translating among data storage formats associated with the different implementations (such as, different DBMSs or operating systems)

Quality assurance and validation software for the data conversion that are automated testing tools

Computer-aided software engineering (CASE) tools for reverse engineering of the existing application

CASE tools for capturing system design information and presenting it graphically Documentation tools such as cross-reference lists and data attribute generators Commercial off-the-shelf software and software written specifically for the

conversion effort

30.3.3. FacilitiesThis section identifies the physical facilities and accommodations required during the conversion period.

30.3.4. MaterialsThis section lists support materials.

30.3.5. PersonnelThis section describes personnel requirements and any known or proposed staffing, if appropriate. Also describe the training, if any, to be provided for the conversion staff.



QPM #

AQS 200-001-WI

Revision

1


30.3.5.1. Personnel Requirements and Staffing

This section describes the number of personnel, length of time needed, types of skills, and skill levels for the staff required during the conversion period.

30.3.5.2. Training of Conversion Staff

This section addresses the training, if any, necessary to prepare the staff for converting the system. It should provide a training curriculum, which lists the courses to be provided, a course sequence, and a proposed schedule. If appropriate, it should identify by job description which courses should be attended by particular types of staff. Training for users in the operation of the system is not presented in this section, but is normally included in the Training Plan.

30.4. CONVERSION PLAN OUTLINECover Page

Table of Contents

1.0 Introduction

1.1 Purpose and Scope



1.4 Glossary

2.0 Conversion Overview

2.1 System Overview

2.2 System Conversion Overview

2.2.1 Conversion Description

2.2.2 Type of Conversion

2.2.3 Conversion Strategy

2.2.3.1 Hardware Conversion Strategy

2.2.3.2 Software Conversion Strategy

2.2.3.3 Data Conversion Strategy

2.2.3.4 Data Conversion Approach

2.2.3.5 Interfaces

2.2.3.6 Data Quality Assurance and Control

2.2.4 Conversion Risk Factors

2.3 Conversion Tasks

2.3.1 Conversion Planning

2.3.2 Pre-conversion TasksUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


2.3.3 Major Tasks and Procedures

2.3.3.1 Major Task Name

2.3.3.2 Procedures

2.4 Conversion Schedule

2.5 Security

2.5.1 System Security Feature

2.5.2 Security During Conversion

3.0 Conversion Support

3.1 Hardware

3.2 Software

3.3 Facilities

3.4 Materials

3.5 Personnel

3.5.1 Personnel Requirements and Staffing

3.5.2 Training of Conversion Staff



QPM #

AQS 200-001-WI

Revision

1


31 SYSTEM DESIGN DOCUMENT

31.1. INTRODUCTION31.1.1. Purpose and ScopeThis section provides a brief description of the Systems Design Document's purpose and scope.

31.1.2. Project Executive SummaryThis section provides a description of the project from a management perspective and an overview of the framework within which the conceptual system design was prepared. If appropriate, include the information discussed in the subsequent sections in the summary.

31.1.2.1. System Overview

This section describes the system in narrative form using non-technical terms. It should provide a high-level system architecture diagram showing a subsystem breakout of the system, if applicable. The high-level system architecture or subsystem diagrams should, if applicable, show interfaces to external systems. Supply a high-level context diagram for the system and subsystems, if applicable. Refer to the requirements traceability matrix (RTM) in the Functional Requirements Document (FRD), to identify the allocation of the functional requirements into this design document.

31.1.2.2. Design Constraints

This section describes any constraints in the system design (reference any trade-off analyses conducted such, as resource use versus productivity, or conflicts with other systems) and includes any assumptions made by the project team in developing the system design.

31.1.2.3. Future Contingencies

This section describes any contingencies that might arise in the design of the system that may change the development direction. Possibilities include lack of interface agreements with outside agencies or unstable architectures at the time this document is produced. Address any possible workarounds or alternative plans.

31.1.3. Document OrganizationThis section describes the organization of the Systems Design Document.

31.1.4. Points of ContactThis section provides the organization code and title of the key points of contact (and alternates if appropriate) for the information system development effort. These points of contact should include the Project Manager, System Proponent, User Organization, Quality Assurance (QA) Manager, Security Manager, and Configuration Manager, as appropriate.

31.1.5. Project ReferencesThis section provides a bibliography of key project references and deliverables that have been produced before this point. For example, these references might include the Project Management Plan, Feasibility Study, CBA, Acquisition Plan, QA Plan, CM Plan, FRD, and ICD.



QPM #

AQS 200-001-WI

Revision

1


31.1.6. GlossarySupply a glossary of all terms and abbreviations used in this document. If the glossary is several pages in length, it may be included as an appendix.

31.2. SYSTEM ARCHITECTUREIn this section, describe the system and/or subsystem(s) architecture for the project. References to external entities should be minimal, as they will be described in detail in Section 6, External Interfaces.

31.2.1. System Hardware ArchitectureIn this section, describe the overall system hardware and organization. Include a list of hardware components (with a brief description of each item) and diagrams showing the connectivity between the components. If appropriate, use subsections to address each subsystem.

31.2.2. System Software ArchitectureIn this section, describe the overall system software and organization. Include a list of software modules (this could include functions, subroutines, or classes), computer languages, and programming computer-aided software engineering tools (with a brief description of the function of each item). Use structured organization diagrams/object-oriented diagrams that show the various segmentation levels down to the lowest level. All features on the diagrams should have reference numbers and names. Include a narrative that expands on and enhances the understanding of the functional breakdown. If appropriate, use subsections to address each module.

Note: The diagrams should map to the FRD data flow diagrams, providing the physical process and data flow related to the FRD logical process and data flow.

31.2.3. Internal Communications ArchitectureIn this section, describe the overall communications within the system; for example, LANs, buses, etc. Include the communications architecture(s) being implemented, such as X.25, Token Ring, etc. Provide a diagram depicting the communications path(s) between the system and subsystem modules. If appropriate, use subsections to address each type of architecture being employed.

Note: The diagrams should map to the FRD context diagrams.

31.3. FILE AND DATABASE DESIGNInteract with the Database Administrator (DBA) when preparing this section. The section should reveal the final design of all database management system (DBMS) files and the non-DBMS files associated with the system under development. Additional information may be added as required for the particular project. Provide a comprehensive data dictionary showing data element name, type, length, source, validation rules, maintenance (create, read, update, delete (CRUD) capability), data stores, outputs, aliases, and description. This document can be included as an appendix.



QPM #

AQS 200-001-WI

Revision

1


31.3.1. Database Management System FilesThis section reveals the final design of the DBMS files and includes the following information, as appropriate (refer to the data dictionary):

Refined logical model; provide normalized table layouts, entity relationship diagrams, and other logical design information

A physical description of the DBMS schemas, sub-schemas, records, sets, tables, storage page sizes, etc.

Access methods (such as indexed, via set, sequential, random access, sorted pointer array, etc.)

Estimate of the DBMS file size or volume of data within the file, and data pages, including overhead resulting from access methods and free space

Definition of the update frequency of the database tables, views, files, areas, records, sets, and data pages; estimate the number of transactions if the database is an online transaction-based system

31.3.2. Non-Database Management System FilesIn this section, provide the detailed description of all non-DBMS files and include a narrative description of the usage of each file--including if the file is used for input, output, or both; if this file is a temporary file; an indication of which modules read and write the file, etc.; and file structures (refer to the data dictionary). As appropriate, the file structure information should:

Identify record structures, record keys or indexes, and reference data elements within the records

Define record length (fixed or maximum variable length) and blocking factors Define file access method--for example, index sequential, virtual sequential,

random access, etc. Estimate the file size or volume of data within the file, including overhead

resulting from file access methods Define the update frequency of the file; if the file is part of an online transaction-

based system, provide the estimated number of transactions per unit time, and the statistical mean, mode, and distribution of those transactions

31.4. HUMAN-MACHINE INTERFACEThis section provides the detailed design of the system and subsystem inputs and outputs relative to the user/operator. Any additional information may be added to this section and may be organized according to whatever structure best presents the operator input and output designs. Depending on the particular nature of the project, it may be appropriate to repeat these sections at both the subsystem and design module levels. Additional information may be added to the subsections if the suggested lists are inadequate to describe the project inputs and outputs.



QPM #

AQS 200-001-WI

Revision

1


31.4.1. InputsThis section is a description of the input media used by the operator for providing information to the system; show a mapping to the high-level data flows described in Section 1.2.1, System Overview. For example, data entry screens, optical character readers, bar scanners, etc. If appropriate, the input record types, file structures, and database structures provided in Section 3, File and Database Design, may be referenced. Include data element definitions, or refer to the data dictionary.

Provide the layout of all input data screens or graphical user interfaces (GUIs) (for example, windows). Provide a graphic representation of each interface. Define all data elements associated with each screen or GUI, or reference the data dictionary.

This section should contain edit criteria for the data elements, including specific values, range of values, mandatory/optional, alphanumeric values, and length. Also address data entry controls to prevent edit bypassing.

Discuss the miscellaneous messages associated with operator inputs, including the following:

Copies of form(s) if the input data are keyed or scanned for data entry from printed forms

Description of any access restrictions or security considerations Each transaction name, code, and definition, if the system is a transaction-based

processing system Incorporation of the Privacy Act statement into the screen flow, if the system is

covered by the Privacy Act

31.4.2. OutputsThis section describes of the system output design relative to the user/operator; show a mapping to the high-level data flows described in Section 1.2.1. System outputs include reports, data display screens and GUIs, query results, etc. The output files are described in Section 3 and may be referenced in this section. The following should be provided, if appropriate:

Identification of codes and names for reports and data display screens Description of report and screen contents (provide a graphic representation of

each layout and define all data elements associated with the layout or reference the data dictionary)

Description of the purpose of the output, including identification of the primary users Report distribution requirements, if any (include frequency for periodic reports)

Description of any access restrictions or security considerations

31.5. DETAILED DESIGNThis section provides the information needed for a system development team to actually build and integrate the hardware components and code, to integrate the software modules, and to interconnect the hardware and software segments into a functional product. Additionally, this section addresses the detailed procedures for combining separate COTS packages into a single



QPM #

AQS 200-001-WI

Revision

1


system. Every detailed requirement should map back to the FRD, and the mapping should be presented in an update to the RTM and include the RTM as an appendix to this design document.

31.5.1. Hardware Detailed DesignA hardware component is the lowest level of design granularity in the system. Depending on the design requirements, there may be one or more components per system. This section should provide enough detailed information about individual component requirements to correctly build and/or procure all the hardware for the system (or integrate COTS items).

If there are many components or if the component documentation is extensive, place it in an appendix or reference a separate document. Add additional diagrams and information, if necessary, to describe each component and its functions, adequately. Industry-standard component specification practices should be followed. For COTS procurements, if a specific vendor has been identified, include appropriate item names. Include the following information in the detailed component designs (as applicable):

Power input requirements for each component Signal impedances and logic states Connector specifications (serial/parallel, 11-pin, male/female, etc.) Memory and/or storage space requirements Processor requirements (speed and functionality) Graphical representation depicting the number of hardware items (for example,

monitors, printers, servers, I/O devices), and the relative positioning of the components to each other

Cable type(s) and length(s) User interfaces (buttons, toggle switches, etc.) Hard drive/floppy drive/CD-ROM requirements Monitor resolution

31.5.2. Software Detailed DesignA software module is the lowest level of design granularity in the system. Depending on the software development approach, there may be one or more modules per system. This section should provide enough detailed information about logic and data necessary to completely write source code for all modules in the system (and/or integrate COTS software programs).

If there are many modules or if the module documentation is extensive, place it in an appendix or reference a separate document. Add additional diagrams and information, if necessary, to describe each module, its functionality, and its hierarchy. Industry-standard module specification practices should be followed. Include the following information in the detailed module designs:

A narrative description of each module, its function(s), the conditions under which it is used (called or scheduled for execution), its overall processing, logic, interfaces to other modules, interfaces to external systems, security requirements, etc.; explain any algorithms used by the module in detail.



QPM #

AQS 200-001-WI

Revision

1


For COTS packages, specify any call routines or bridging programs to integrate the package with the system and/or other COTS packages (for example, Dynamic Link Libraries)

Data elements, record structures, and file structures associated with module input and output

Graphical representation of the module processing, logic, flow of control, and algorithms, using an accepted diagramming approach (for example, structure charts, action diagrams, flowcharts, etc.)

Data entry and data output graphics; define or reference associated data elements; if the project is large and complex or if the detailed module designs will be incorporated into a separate document, then it may be appropriate to repeat the screen information in this section

Report layout

31.5.3. Internal Communications Detailed DesignIf the system includes more than one component there may be a requirement for internal communications to exchange information, provide commands, or support input/output functions. This section should provide enough detailed information about the communication requirements to correctly build and/or procure the communications components for the system. Include the following information in the detailed designs (as appropriate):

The number of servers and clients to be included on each area network Specifications for bus timing requirements and bus control Format(s) for data being exchanged between components Graphical representation of the connectivity between components, showing the

direction of data flow (if applicable), and approximate distances between components; information should provide enough detail to support the procurement of hardware to complete the installation at a given location

LAN topology

31.6. EXTERNAL INTERFACESExternal systems are any systems that are not within the scope of the system under development, regardless whether the other systems are managed by the AVS or another agency. In this section, describe the electronic interface(s) between this system and each of the other systems and/or subsystem(s), emphasizing the point of view of the system being developed.

31.6.1. Interface ArchitectureIn this section, describe the interface(s) between the system being developed and other systems; for example, batch transfers, queries, etc. Include the interface architecture(s) being implemented, such as wide area networks, gateways, etc. Provide a diagram depicting the communications path(s) between this system and each of the other systems, which should map to the context diagrams in Section 1.2.1. If appropriate, use subsections to address each interface being implemented.



QPM #

AQS 200-001-WI

Revision

1


31.6.2. Interface Detailed DesignFor each system that provides information exchange with the system under development, there is a requirement for rules governing the interface. This section should provide enough detailed information about the interface requirements to correctly format, transmit, and/or receive data across the interface. Include the following information in the detailed design for each interface (as appropriate):

The data format requirements; if there is a need to reformat data before they are transmitted or after incoming data is received, tools and/or methods for the reformat process should be defined

Specifications for hand-shaking protocols between the two systems; include the content and format of the information to be included in the hand-shake messages, the timing for exchanging these messages, and the steps to be taken when errors are identified

Format(s) for error reports exchanged between the systems; should address the disposition of error reports; for example, retained in a file, sent to a printer, flag/alarm sent to the operator, etc.

Graphical representation of the connectivity between systems, showing the direction of data flow

Query and response descriptions

If a formal ICD exists for a given interface, the information can be copied, or the ICD can be referenced in this section.

31.7. SYSTEM INTEGRITY CONTROLSSensitive ADP systems use information for which the loss, misuse, modification of, or unauthorized access to that information could affect the national interest, the conduct of Federal programs, or the privacy to which individuals are entitled under Section 552a of Title 5, U.S. Code, but that has not been specifically authorized under criteria established by an Executive Order or an act of Congress to be kept classified in the interest of national defense or foreign policy.

Developers of sensitive AVS ADP systems are required to develop specifications for the following minimum levels of control:

Internal security to restrict access of critical data items to only those access types required by users

Audit procedures to meet control, reporting, and retention period requirements for operational and management reports

Application audit trails to dynamically audit retrieval access to designated critical data

Standard Tables to be used or requested for validating data fields Verification processes for additions, deletions, or updates of critical data Ability to identify all audit information by user identification, network terminal

identification, date, time, and data accessed or changed



QPM #

AQS 200-001-WI

Revision

1


31.8. DESIGN DOCUMENT OUTLINECover Page

Table of Contents

1.0 Introduction


1.2 Project Executive Summary

1.2.1 System Overview

1.2.2 Design Constraints

1.2.3 Future Contingencies

1.3 Document Organization



1.6 Glossary

2.0 System Architecture

2.1 System Hardware Architecture

2.2 System Software Architecture

2.3 Internal Communications Architecture

3.0 File and Database Design

3.1 Database Management System Files

3.2 Non-Database Management System Files

4.0 Human-Machine Interface

4.1 Inputs

4.2 Outputs

5.0 Detailed Design

5.1 Hardware Detailed Design

5.2 Software Detailed Design

5.3 Internal Communications Detailed Design

6.0 External Interfaces

6.1 Interface Architecture

6.2 Interface Detailed Design

7.0 System Integrity Controls



QPM #

AQS 200-001-WI

Revision

1


Appendix X - Requirements Traceability Matrix



QPM #

AQS 200-001-WI

Revision

1


32 IMPLEMENTATION PLAN

The Implementation Plan describes how the information system will be deployed, installed and transitioned into an operational system. The plan contains an overview of the system, a brief description of the major tasks involved in the implementation, the overall resources needed to support the implementation effort (such as hardware, software, facilities, materials, and personnel), and any site-specific implementation requirements. The plan is developed during the Design Phase and is updated during the Development Phase; the final version is provided in the Integration and Test Phase and is used for guidance during the Implementation Phase. The outline shows the structure of the Implementation Plan.

32.1. INTRODUCTIONThis section provides an overview of the information system and includes any additional information that may be appropriate.

32.1.1. PurposeThis section describes the purpose of the Implementation Plan. Reference the system name and identify information about the system to be implemented.

32.1.2. System OverviewThis section provides a brief overview of the system to be implemented, including a description of the system and its organization.

32.1.2.1. System Description

This section provides an overview of the processes the system is intended to support. If the system is a database or an information system, provide a general discussion of the description of the type of data maintained and the operational sources and uses of those data.

32.1.2.2. System Organization

This section provides a brief description of system structure and the major system components essential to the implementation of the system. It should describe both hardware and software, as appropriate. Charts, diagrams, and graphics may be included as necessary.

32.1.3. Project ReferencesThis section provides a bibliography of key project references and deliverables that have been produced before this point in the project development. For example, these references might include the Project Plan, Acquisition Plan, FRD, Test Plan, Conversion Plan, and System Design Document.

32.1.4. GlossaryProvide a glossary of all terms and abbreviations used in the manual. If it is several pages in length, it may be placed in an appendix.



QPM #

AQS 200-001-WI

Revision

1


32.2. MANAGEMENT OVERVIEWThe subsequent sections provide a brief description of the implementation and major tasks involved in this section.

32.2.1. Description of ImplementationThis section provides a brief description of the system and the planned deployment, installation, and implementation approach.

32.2.2. Points of ContactIn this section, identify the System Proponent, the name of the responsible organization(s), and titles and telephone numbers of the staff who serve as points of contact for the system implementation. These points of contact could include the Project Manager, Program Manager, Security Manager, Database Administrator, Configuration Management Manager, or other managers with responsibilities relating to the system implementation. The site implementation representative for each field installation or implementation site should also be included, if appropriate. List all managers and staff with whom the implementation must be coordinated.

32.2.3. Major TasksThis section provides a brief description of each major task required for the implementation of the system. Add as many subsections as necessary to this section to describe all the major tasks adequately. The tasks described in this section are not site-specific, but generic or overall project tasks that are required to install hardware and software, prepare data, and verify the system. Include the following information for the description of each major task, if appropriate:

What the task will accomplish Resources required to accomplish the task Key person(s) responsible for the task Criteria for successful completion of the task Examples of major tasks are the following:

Providing overall planning and coordination for the implementation Providing appropriate training for personnel Ensuring that all manuals applicable to the implementation effort are

available when needed Providing all needed technical assistance Scheduling any special computer processing required for the

implementation Performing site surveys before implementation Ensuring that all prerequisites have been fulfilled before the

implementation date Providing personnel for the implementation team Acquiring special hardware or software Performing data conversion before loading data into the system



QPM #

AQS 200-001-WI

Revision

1


Preparing site facilities for implementation

32.2.4. Implementation ScheduleIn this section, provide a schedule of activities to be accomplished during implementation. Show the required tasks (described in Section 2.3, Major Tasks) in chronological order, with the beginning and end dates of each task.

32.2.5. SecurityIf appropriate for the system to be implemented, include an overview of the system security features and requirements during the implementation. If the Privacy Act covers the system, provide Privacy Act concerns.

32.2.5.1. System Security Features

In this section, provide an overview and discussion of the security features that will be associated with the system when it is implemented. It should include the primary security features associated with the system hardware and software. Security and protection of sensitive bureau data and information should be discussed, if applicable. Reference the sections of previous deliverables that address system security issues, if appropriate.

32.2.5.2. Security during Implementation

This section addresses security issues specifically related to the implementation effort, if any. For example, if LAN servers or workstations will be installed at a site with sensitive data preloaded on non-removable hard disk drives, address how security would be provided for the data on these devices during shipping, transport, and installation because theft of the devices could compromise the sensitive data.

32.3. IMPLEMENTATION SUPPORTThis section describes the support software, materials, equipment, and facilities required for the implementation, as well as the personnel requirements and training necessary for the implementation. The information provided in this section is not site-specific. If there are additional support requirements not covered by the subsequent sections, others may be added as needed.

32.3.1. Hardware, Software, Facilities, and MaterialsIn this section, list support software, materials, equipment, and facilities required for the implementation, if any.

32.3.1.1. Hardware

This section provides a list of support equipment and includes all hardware used for testing the implementation. For example, if a client/server database is implemented on a LAN, a network monitor or "snuffer" might be used, along with test programs, to determine the performance of the database and LAN at high-utilization rates. If the equipment is site-specific, list it in Section 4, Implementation Requirements by Site.



QPM #

AQS 200-001-WI

Revision

1


32.3.1.2. Software

This section provides a list of software and databases required to support the implementation. Identify the software by name, code, or acronym. Identify which software is commercial off-the-shelf and which is AVS-specific. Identify any software used to facilitate the implementation process. If the software is site-specific, list it in Section 4.

32.3.1.3. Facilities

In this section, identify the physical facilities and accommodations required during implementation. Examples include physical workspace for assembling and testing hardware components, desk space for software installers, and classroom space for training the implementation staff. Specify the hours per day needed, number of days, and anticipated dates. If the facilities needed are site-specific, provide this information in Section 4, Implementation Requirements by Site.

32.3.1.4. Material

This section provides a list of required support materials, such as magnetic tapes and disk packs.

32.3.2. PersonnelThis section describes personnel requirements and any known or proposed staffing requirements, if appropriate. Also describe the training, if any, to be provided for the implementation staff.

32.3.2.1. Personnel Requirements and Staffing

In this section, describe the number of personnel, length of time needed, types of skills, and skill levels for the staff required during the implementation period. If particular staff members have been selected or proposed for the implementation, identify them and their roles in the implementation.

32.3.2.2. Training of Implementation Staff

This section addresses the training, if any, necessary to prepare staff for implementing and maintaining the system; it does not address user training, which is the subject of the Training Plan. Describe the type and amount of training required for each of the following areas, if appropriate, for the system:

System hardware/software installation System support System maintenance and modification Present a training curriculum listing the courses that will be provided, a course

sequence, and a proposed schedule. If appropriate, identify which courses particular types of staff should attend by job position description.

If training will be provided by one or more commercial vendors, identify them, the course name(s), and a brief description of the course content.



QPM #

AQS 200-001-WI

Revision

1


If the training will be provided by AVS staff, provide the course name(s) and an outline of the content of each course. Identify the resources, support materials, and proposed instructors required to teach the course(s).

32.3.3. Performance MonitoringThis section describes the performance monitoring tool and techniques and how it will be used to help decide if the implementation is successful.

32.3.4. CM InterfaceThis section describes the interactions required with the CM representative on CM-related issues, such as when software listings will be distributed, and how to confirm that libraries have been moved from the development to the production environment.

32.4. IMPLEMENTATION REQUIREMENTS BY SITEThis section describes specific implementation requirements and procedures. If these requirements and procedures differ by site, repeat these subsections for each site; if they are the same for each site, or if there is only one implementation site, use these subsections only once.

The "X" in the subsection number should be replaced with a sequenced number beginning with 1. Each subsection with the same value of "X" is associated with the same implementation site. If a complete set of subsections will be associated with each implementation site, then "X" is assigned a new value for each site.

32.4.1. Site Name or Identification for Site XThis section provides the name of the specific site or sites to be discussed in the subsequent sections.

32.4.1.1. Site Requirements

This section defines the requirements that must be met for the orderly implementation of the system and describes the hardware, software, and site-specific facilities requirements for this area.

Any site requirements that do not fall into the following three categories and were not described in Section 3, Implementation Support, may be described in this section, or other subsections may be added following Facilities Requirements below:

Hardware Requirements--Describe the site-specific hardware requirements necessary to support the implementation (such as, LAN hardware for a client/server database designed to run on a LAN).

Software Requirements--Describe any software required to implement the system (such as, software specifically designed for automating the installation process).

Data Requirements--Describe specific data preparation requirements and data that must be available for the system implementation. An example would be the assignment of individual IDs associated with data preparation.



QPM #

AQS 200-001-WI

Revision

1


Facilities Requirements--Describe the site-specific physical facilities and accommodations required during the system implementation period. Some examples of this type of information are provided in Section 3.

32.4.1.2. Site Implementation Details

This section addresses the specifics of the implementation for this site. Include a description of the implementation team, schedule, procedures, and database and data updates. This section should also provide information on the following:

Team--If an implementation team is required, describe its composition and the tasks to be performed at this site by each team member.

Schedule--Provide a schedule of activities, including planning and preparation, to be accomplished during implementation at this site. Describe the required tasks in chronological order with the beginning and end dates of each task. If appropriate, charts and graphics may be used to present the schedule.

Procedures--Provide a sequence of detailed procedures required to accomplish the specific hardware and software implementation at this site. If necessary, other documents may be referenced. If appropriate, include a step-by-step sequence of the detailed procedures. A checklist of the installation events may be provided to record the results of the process.

If the site operations startup is an important factor in the implementation, then address startup procedures in some detail. If the system will replace an existing operational system, then address the startup and cutover processes in detail. If there is a period of parallel operations with an existing system, address the startup procedures that include technical and operations support during the parallel cycle and the consistency of data within the databases of the two systems.

Database--Describe the database environment where the software system and the database(s), if any, will be installed. Include a description of the different types of database and library environments (such as, production, test, and training databases).

Include the host computer database operating procedures, database file and library naming conventions, database system generation parameters, and any other information needed to effectively establish the system database environment.

Include database administration procedures for testing changes, if any, to the database management system before the system implementation.

Data Update--If data update procedures are described in another document, such as the operations manual or conversion plan, that document may be referenced here. The following are examples of information to be included:

Control inputs Operating instructions Database data sources and inputs Output reports Restart and recovery procedures



QPM #

AQS 200-001-WI

Revision

1


32.4.1.3. Back-Off Plan

This section specifies when to make the go/no go decision and the factors to be included in making the decision. The plan then goes on to provide a detailed list of steps and actions required to restore the site to the original, pre-conversion condition.

32.4.1.4. Post-implementation Verification

This section describes the process for reviewing the implementation and deciding if it was successful. It describes how an action item list will be created to rectify any noted discrepancies. It also references the Back-Off Plan for instructions on how to back-out the installation, if, as a result of the post-implementation verification, a no-go decision is made.

32.5. IMPLEMENTATION PLAN OUTLINECover Page

Table of Contents

1.0 Introduction

1.1 Purpose

1.2 System Overview

1.2.1 System Description

1.2.2 System Organization


1.4 Glossary

2.0 Management Overview

2.1 Description of Implementation


2.3 Major Tasks

2.4 Implementation Schedule

2.5 Security

2.5.1 System Security Features

2.5.2 Security during Implementation

3.0 Implementation Support

3.1 Hardware, Software, Facilities, and Materials

3.1.1 Hardware

3.1.2 Software

3.1.3 Facilities

3.1.4 MaterialUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


3.2 Personnel

3.2.1 Personnel Requirements and Staffing

3.2.2 Training of Implementation Staff

3.3 Performance Monitoring

3.4 CM Interface

4.0 Implementation Requirements by Site

4.1 Site Name or Identification for Site X

4.1.1 Site Requirements

4.1.2 Site Implementation Details

4.1.3 Back-Off Plan

4.1.4 Post-implementation Verification



QPM #

AQS 200-001-WI

Revision

1


33 MAINTENANCE MANUAL

The Maintenance Manual provides maintenance personnel with the information necessary to maintain the system effectively. The manual provides the definition of the software support environment, the roles and responsibilities of maintenance personnel, and the regular activities essential to the support and maintenance of program modules, job streams, and database structures.

In addition to the items identified for inclusion in the Maintenance Manual, additional information may be provided to facilitate the maintenance and modification of the system. Appendices to document various maintenance procedures, standards, or other essential information may be added to this document as needed.

33.1. INTRODUCTIONThis section provides general reference information regarding the Maintenance Manual. Whenever appropriate, additional information may be added to this section.

33.1.1. PurposeIn this section, describe the purpose of the manual and reference the system name and identifying information about the system and its programs.

33.1.2. Points of ContactThis section identifies the organization(s) responsible for system development, maintenance, and use. This section also identifies points of contact (and alternate if appropriate) for the system within each organization.

33.1.3. Project ReferenceThis section provides a bibliography of key project references and deliverables produced during the information system development life cycle. If appropriate, reference the FRD, Systems Design Document, Test Plan, Test Analysis Report(s), Operations Manual, User Manual, load module description, source code description, and job control language (JCL) description.

33.1.4. GlossaryProvide a glossary with definitions of all terms, abbreviations, and acronyms used in the manual. If the glossary is several pages in length, place it as an appendix.

33.2. SYSTEM DESCRIPTIONThe subsequent sections provide an overview of the system to be maintained.

33.2.1. System ApplicationThis section provides a brief description of the purpose of the system, the functions it performs, and the business processes that the system is intended to support. If the system is a database or an information system, include a general description of the type of data maintained, and the operational sources and uses of those data.



QPM #

AQS 200-001-WI

Revision

1


33.2.2. System OrganizationIn this section, provide a brief description of the system structure, major system components, and the functions of each major system component. Include charts, diagrams, and graphics as necessary.

33.2.3. Security and the Privacy ActThis section provides an overview of the system's security controls and the need for security and protection of sensitive data. For example, include information regarding procedures to log on/off of the system, provisions for the use of special passwords, access verification, and access statuses as appropriate. If the system handles sensitive or Privacy Act information, include information regarding labeling system outputs as sensitive, or Privacy Act-related. In addition, if the system is covered by the Privacy Act, include a warning of the Privacy Act's civil and criminal penalties concerning the unauthorized use and disclosure of system data.

33.2.4. System Requirements Cross-ReferenceThis section contains an exhibit that cross-references the detailed system requirements with the system design document and test plan. This document, also referred to as a traceability matrix in other documents, assists maintenance personnel by tracing how the user requirements developed in the FRD are met in other products of the life cycle. Because this information is provided in the system design document, it may be appropriate to repeat or enhance that information in this section.

33.3. SUPPORT ENVIRONMENTThis section describes the operating and support environment for the system and program(s). Include a discussion of the equipment, support software, database characteristics, and personnel requirements for supporting maintenance of the system and its programs.

33.3.1. Equipment EnvironmentThis section describes the equipment support environment, including the development, maintenance, and target host computer environments. Describe telecommunications and facility requirements, if any.

33.3.1.1. Computer Hardware

This section discusses the computer configuration on which the software is hosted and its general characteristics. The section should also identify the specific computer equipment required to support software maintenance if that equipment differs from the host computer. For example, if software development and maintenance are performed on a platform that differs from the target host environment, describe both environments. Describe any miscellaneous computer equipment required in this section, such as hardware probe boards that perform hardware-based monitoring and debugging of software. Include any telecommunications equipment.

33.3.1.2. Facilities

This section describes the special facility requirements, if any, for system and program maintenance and includes any telecommunications facilities required to test the software.



QPM #

AQS 200-001-WI

Revision

1


33.3.2. Support SoftwareThis section lists all support software--such as operating systems, transaction processing systems, and database management systems (DBMSs)--as well as software used for the maintenance and testing of the system. Include the appropriate version or release numbers, along with their documentation references, with the support software lists.

33.3.3. Database CharacteristicsThis section contains an overview of the nature and content of each database used by the system. Reference other documents for a detailed description, including the system design document as appropriate.

33.3.4. PersonnelThis section describes the special skills required for the maintenance personnel. These skills may include knowledge of specific versions of operating systems, transaction processing systems, high-level languages, screen and display generators, DBMSs, testing tools, and computer-aided system engineering tools.

33.4. SYSTEM MAINTENANCE PROCEDURESThis section contains information on the procedures necessary for programmers to maintain the software.

33.4.1. ConventionsThis section describes all rules, schemes, and conventions used within the system. Examples of this type of information include the following:

System-wide labeling, tagging, and naming conventions for programs, units, modules, procedures, routines, records, files, and data element fields

Procedures and standards for charts and listings Standards for including comments in programs to annotate maintenance

modifications and changes Abbreviations and symbols used in charts, listings, and comments sections of

programs

If the conventions follow standard programming practices and a standards document, that document may be referenced, provided that it is available to the maintenance team.

33.4.2. Verification ProceduresThis section includes requirements and procedures necessary to check the performance of the system following modification or maintenance of the system's software components. Address the verification of the system-wide correctness and performance.

Present, in detail, system-wide testing procedures. Reference the original development test plan if the testing replicates development testing. Describe the types and source(s) of test data in detail.



QPM #

AQS 200-001-WI

Revision

1


33.4.3. Error ConditionsThis section describes all system-wide error conditions that may be encountered within the system, including an explanation of the source(s) of each error and recommended methods to correct each error.

33.4.4. Maintenance SoftwareThis section references any special maintenance software and its supporting documentation used to maintain the system.

33.4.5. Maintenance ProcedureThis section describes step-by-step, system-wide maintenance procedures, such as procedures for setting up and sequencing inputs for testing. In addition, present standards for documenting modifications to the system.

33.5. SOFTWARE UNIT MAINTENANCE PROCEDURESFor each software unit within the system, provide the information requested. If the information is identical for each of the software units, it is not necessary to repeat it for each software unit. If the information in any of the areas discussed below is identical to information provided in Section 4, System Maintenance Procedures, for the system maintenance procedures, then reference that area. This section should contain the following:

Unit Name And Identification--Provide the name or identification of each software unit that is a component of the system. Repeat the following information for each unit name.

Description--Provide a brief narrative description of the software unit. Reference other sections within the life cycle that contains more detailed descriptive material.

Requirements Cross-Reference--Include the detailed user requirements satisfied by this particular software unit. It may be a matrix that traces the system requirements from the FRD through the system design document and test plan for the specific software units. Other life cycle documentation may be referenced as appropriate.

Conventions--Describe all rules, schemes, and conventions used within the program. If this information is program-specific, provide that information here. If the conventions are all system-wide, discuss them Section 4. If the conventions follow standard programming practices and a standards document, that document may be referenced here.

Verification Procedures--Include the requirements and procedures necessary to check the performance of the program following modification or maintenance and addresses the verification of program correctness, performance, and detailed testing procedures. If the testing replicates development testing, it may be appropriate to reference the original development test plan.

Error Conditions--Describe all program-specific error conditions that may be encountered provide an explanation of the source(s) of each error, and recommend methods to correct each error. If these error conditions are the same as the system-wide error conditions described in Section 4.3, Error Conditions, that section may be referenced here.

Listings--Provide a reference to the location of the program listings.UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


33.6. MAINTENANCE MANUAL OUTLINECover Page

Table of Contents

1.0 Introduction

1.1 Purpose



1.4 Glossary

2.0 System Description

2.1 System Application

2.2 System Organization

2.3 Security and the Privacy Act

2.4 System Requirements Cross-Reference

3.0 Support Environment

3.1 Equipment Environment

3.2 Support Software

3.3 Database Characteristics

3.4 Personnel

4.0 System Maintenance Procedures

4.1 Conventions

4.2 Verification Procedures

4.3 Error Conditions

4.4 Maintenance Software

4.5 Maintenance Procedures

5.0 Software Unit Maintenance Procedures



QPM #

AQS 200-001-WI

Revision

1


34 OPERATIONS MANUAL

The Operations Manual provides computer control personnel and computer operators with a detailed operational description of the information system and its associated environments, such as machine room operations and procedures.

34.1. GENERAL34.1.1. Introduction and PurposeDescribe the introduction and purpose of the Operations Manual, the name of the system to which it applies, and the type of computer operation.

34.1.2. Project ReferencesList, at a minimum, the User Manual, Maintenance Manual, and other pertinent documentation.

34.1.3. GlossaryList any definitions or terms unique to this document or computer operation and subject to interpretation by the user of this document.

34.2. SYSTEM OVERVIEW34.2.1. System ApplicationProvide a brief description of the system, including its purpose and uses.

34.2.2. System OrganizationDescribe the operation of the system by the use of a chart depicting operations and interrelationships.

34.2.3. Software InventoryList the software units, to include name, identification, and security considerations. Identify software necessary to resume operation of the system in case of emergency.

34.2.4. Information InventoryProvide information about data files and databases that are produced or referenced by the system.

34.2.4.1. Resource Inventory

List all permanent files and databases that are referenced, created, or updated by the system.

34.2.4.2. Report Inventory

List all reports produced by the system. Include report name and the software that generates it.

34.2.5. Processing OverviewProvide information that is applicable to the processing of the system. Include system restrictions, waivers of operational standards, and interfaces with other systems.



QPM #

AQS 200-001-WI

Revision

1


34.2.6. Communications OverviewDescribe the communications functions and process of the system.

34.2.7. SecurityDescribe the security considerations associated with the system.

34.2.8. Privacy Act WarningInclude a Privacy Act warning if the system is covered by the Privacy Act.

34.3. DESCRIPTION OF RUNS34.3.1. Run InventoryList the runs showing the software components, the job control batch file names, run jobs, and purpose of each run if any portion of the system is run in batch mode. For online

Transaction-based processing, provide an inventory of all software components that must be loaded for the software system to be operational.

34.3.2. Run SequenceProvide a schedule of acceptable phasing of the software system into a logical series of operations. If the system is a batch system, provide the execution schedule, which shows, at a minimum, the following:

Job dependencies Day of week/month/date for execution Time of day or night (if significant) Expected run time in computer units

34.3.3. Diagnostic ProceduresDescribe the diagnostic or error-detection features of the system, the purpose of the diagnostic features and the setup and execution procedures for any software diagnostic procedures.

34.3.4. Error MessagesList all error codes and messages, with operator responses as appropriate.

34.3.5. Run DescriptionsProvide detailed information needed to execute system runs. For each run include the information discussed in the subsequent sections.

34.3.5.1. Control Inputs

Describe all operator job control inputs--for example, starting the run, selecting run execution options, activating an online or transaction-based system, and running the system through remote devices, if appropriate.



QPM #

AQS 200-001-WI

Revision

1


34.3.5.2. Primary User Contact

Identify the user contact (and alternate if appropriate) for the system, including the person's name, organization, address, and telephone number.

34.3.5.3. Data Inputs

Describe the following if data input is required at production time:

Who is responsible for the source data? Format of the data Data validation requirements Disposition of input source and created data

34.3.5.4. Output Reports

Identify the report names, distribution requirements, and any identifying numbers expected to be output from the run. Describe reports to be produced from the system run by other than standard means.

34.3.5.5. Restart/Recovery Procedures

Provide instructions by which the operator can initiate restart or recovery procedures for the run.

34.3.5.6. Backup Procedures

Provide instructions by which the operator can initiate backup procedures. Cross-reference applicable instructions with procedures in the contingency plan.

34.3.5.7. Problem Reporting/Escalation Procedure

Provide instructions for reporting problems to a point of contact. Include the person's name and phone numbers (that is, office, home, pager, etc.).

34.4. OPERATIONS MANUAL OUTLINECover Page

Table of Contents

1.0 General

1.1 Introduction and Purpose


1.3 Glossary

2.0 System Overview



2.3 Software Inventory

2.4 Information Inventory



QPM #

AQS 200-001-WI

Revision

1


2.4.1 Resource Inventory

2.4.2 Report Inventory

2.5 Processing Overview

2.6 Communications Overview

2.7 Security

2.8 Privacy Act Warning

3.0 Description of Runs

3.1 Run Inventory

3.2 Run Sequence

3.3 Diagnostic Procedures

3.4 Error Messages

3.5 Run Descriptions

3.5.1 Control Inputs

3.5.2 Primary User Contact

3.5.3 Data Inputs

3.5.4 Output Reports

3.5.5 Restart/Recovery Procedures

3.5.6 Backup Procedures

3.5.7 Problem Reporting/Escalation Procedures



QPM #

AQS 200-001-WI

Revision

1


35 SYSTEM ADMINISTRATION MANUAL

A Systems Administration Manual serves the purpose of an Operations Manual in distributed (client/server) applications.

35.1. GENERAL

35.1.1. Introduction and PurposeThis section introduces and describes the purpose of the Systems Administration Manual, the name of the system to which it applies, and the type of computer operation.

35.1.2. Project ReferencesThis section lists, at a minimum, the User Manual, Maintenance Manual, and other pertinent available systems documentation.

35.1.3. GlossaryThis section lists all definitions or terms unique to this document or computer operation and subject to interpretation by the user of this document.

35.2. SYSTEM OVERVIEW

35.2.1. System ApplicationThis section provides a brief description of the system, including its purpose and uses.

35.2.2. System OrganizationThis section describes the organization of the system by the use of a chart depicting components and their interrelationships.

35.2.3. Information InventoryThis section provides information about data files, and the databases that are produced or referenced by the system.

35.2.3.1. Resource Inventory

This section lists all permanent files and databases that are referenced, created, or updated by the system.

35.2.3.2. Report Inventory

This section lists all reports produced by the system, including each report name and the software that generates it.

35.2.4. Processing OverviewThis section provides information that is applicable to the processing of the system. It includes system restrictions, waivers of operational standards, and interfaces with other systems.



QPM #

AQS 200-001-WI

Revision

1


35.2.5. Communications OverviewThis section describes the communications functions and process of the system.

35.2.6. SecurityThis section describes the security considerations associated with the system.

35.2.7. Privacy Act WarningIf this system is covered by the Privacy Act, then this section provides the appropriate Privacy Act notice and warning.

35.3. SITE PROFILE(S)This section contains information pertaining to the site(s) where the application is running. That information includes the information contained in the subsequent sections.

35.3.1. Site Location(s)This is the official address(es) of the site(s).

35.3.2. Primary SiteFor the site(s) designated as primary, this section describes the essential personnel names and phone numbers for the automated data processing site contacts.

35.4. SYSTEMS ADMINISTRATIONThis section introduces the responsibilities of the System Administrator, as discussed in the subsequent sections.

35.4.1. User and Group AccountsThis section introduces topics related to system users.

35.4.1.1. Adding/Deleting Users

This section describes procedures to create/delete user logins and password accounts.

35.4.1.2. Setting User Permissions

This section describes procedures to give users/restrict access to certain files.

35.4.1.3. Adding/Deleting User Groups

This section contains procedures to create/delete user groups.

35.4.1.4. Setting User Roles/Responsibilities

This section describes the roles that are granted to each group or individual user(s).

35.4.2. Server AdministrationThis section describes procedures to setup servers, including naming conventions and standards.



QPM #

AQS 200-001-WI

Revision

1


35.4.2.1. Creating Directories

This section describes procedures to create server directories, and a complete description of the existing directories.

35.4.2.2. Building Drive Mappings

This section describes procedures to create server drive mappings, and a complete description of the existing drive mappings.

35.4.3. System Backup ProceduresThis section describes procedures for regularly scheduled backups of the entire network, including program and data storage, and the creation and storage of backup logs.

35.4.3.1. Maintenance Schedule (Daily, Weekly)

This section describes documented daily and weekly backup schedules and procedures. The procedures should include tape labeling, tracking, and rotation instructions.

35.4.3.2. Off-Site Storage Procedures

This section describes the location, schedule, and procedures for off-site storage.

35.4.3.3. Maintaining Backup Log

This section describes procedures for creating and maintaining backup logs.

35.4.4. Printer SupportThis section discusses procedures for installing, operating, and maintaining printers.

35.4.4.1. Maintenance

This section describes maintenance contracts, procedures to include installation and configuration of printer drivers, and equipment information.

35.4.4.2. Print Jobs

This section describes procedures to monitor, delete, and prioritize print jobs.

35.4.5. System MaintenanceThis section discusses procedures for maintaining the file system.

35.4.5.1. Monitoring Performance and System Activity

This section contains procedures to monitor system usage, performance, and activity. This may include descriptions of system monitoring tools, the hours of peak demand, a list of system maintenance schedules, etc.

35.4.5.2. Installing Programs and Operating System Updates

This section includes procedures on how to install and test operating system updates. Once tested, instructions are to be provided to move/install the operating system updates to the operational environment.



QPM #

AQS 200-001-WI

Revision

1


35.4.5.3. Maintaining Audit Records of System Operation

This section describes procedures for the setup and monitoring of the operating system and application audit trails.

35.4.5.4. Maintenance Reports

This section includes procedures to create and update maintenance reports.

35.4.6. Security ProceduresThis section describes the process for obtaining identifications (IDs) and passwords. It includes information concerning network access and confidentiality requirements.

35.4.6.1. Issuing IDs and Passwords

This section describes procedures for issuing IDs and passwords for operating systems and applications.

35.4.6.2. License Agreements

This section describes licensing agreements and procedures for ensuring that all licenses are current.

35.4.7. Network MaintenanceThis section describes procedures to maintain and monitor the data communications network.

35.4.7.1. LAN Design

This section contains a layout of the network.

35.4.7.2. Communications Equipment

This section contains a layout of the telecommunications equipment.

35.4.8. Inventory ManagementThis section contains a complete hardware and software inventory to include make, model, version numbers, and serial numbers.

35.4.8.1. Maintaining Hardware and Software Configurations

This section describes procedures for maintaining the configuration information for the hardware and software actually installed.

35.4.8.2. Maintaining Floor Plans

This section describes procedures for maintaining floor plans showing the location of all installed equipment and how to add/delete/modify the plans.

35.4.8.3. Installing or Upgrading Software/Hardware

This section describes procedures for installing new or upgrading hardware and software.

35.4.8.4. Maintaining Lists of Serial Numbers

This section describes procedures for maintaining all serial number lists required at the site.



QPM #

AQS 200-001-WI

Revision

1


35.4.8.5. Maintain Property Inventory

This section describes procedures for maintaining a property inventory at the site.

35.4.9. Training Backup AdministratorThis section describes how to train a backup administrator.

35.4.10. End-User Support--Procedures for Support and Contract InformationThis section provides necessary end-user contract information and the procedures for providing end-user support.

35.4.10.1. Escalation Procedures

This section describes the formal escalation procedures to be used by System Administrators in response to priority user problem resolution requests.

35.4.11. DocumentationThis section describes the documentation required of System Administrators as they perform system administration.

35.4.11.1. Troubleshooting Issues

This section describes how to conduct and document troubleshooting activities.

35.4.12. Database MaintenanceThis section introduces the responsibilities as they relate to the database and software application maintenance.

35.4.12.1. Database User/Group Access

Describe who provides database access and the procedures for granting access.

35.4.12.2. Adding/Deleting Users to Database

Provide the responsible person who adds and deletes users to the database. Include the procedures for adding/deleting users.

35.4.12.3. Setting User Permissions for Database

Provide the responsible person who sets the permissions for users on the database.

35.4.12.4. Adding/Deleting Groups for Database

Provide the procedures and responsible person for adding/deleting groups of individuals to the database.

35.4.12.5. Re-indexing Database

Provide the procedures and responsible person for re-indexing the database after changes have been made.

35.4.12.6. Packing/Compressing Database

Provide the procedures and responsible person for packing/compressing the database.



QPM #

AQS 200-001-WI

Revision

1


35.4.12.7. Data Entry/Modification/Deletion

Provide the responsible person(s) who can make changes to the database. Include procedures for data entry, modifying, and deleting information from the database.

35.4.12.8. Database Reporting

Provide the responsible person(s) for database reporting. Include what reports are generated, time frames, due dates and storage of the reports.

35.4.12.9. Database Backup and Restore

Provide the person(s) responsible for performing database backup. This information should also be included in the Contingency Plan. Include procedures to follow if the database needed to be restored.

35.4.13. Application Maintenance35.4.13.1. Application User/Group Access

Describe who provides application access and the procedures for granting access.

35.4.13.2. Adding/Deleting Application users

Provide the responsible person who adds and deletes users to the application. Include the procedures for adding/deleting users.

35.4.13.3. Setting User Application Permissions

Provide the responsible person who sets the permissions for users of the application.

35.4.13.4. Adding/Deleting Application Groups

Provide the procedures and responsible person for adding/deleting application groups.

35.4.13.5. Procedures to Start and Stop the Application

Provide who has responsibility to start and stop the application. Include a rationale for stopping the application, and the steps to take to restart after identified problems are corrected.

35.4.13.6. Application Flow Chart

Provide a flow chart depicting how the information moves from the application to the database.

35.4.13.7. Description of Major Program or Sub-program Modules

Describe the processes within the application or module. If more than one module is operating for this system, describe each module.

35.5. SYSTEMS ADMINISTRATION MANUAL OUTLINECover Page

Table of Contents

1.0 General

1.1 Introduction and Purpose



QPM #

AQS 200-001-WI

Revision

1



1.3 Glossary

2.0 System Overview



2.3 Information Inventory

2.3.1 Resource Inventory

2.3.2 Report Inventory

2.4 Processing Overview

2.5 Communications Overview

2.6 Security

2.7 Privacy Act Warning

3.0 Site Profile(s)

3.1 Site Location(s)

3.2 Primary Site

4.0 Systems Administration

4.1 User and Group Accounts

4.1.1 Adding/Deleting Users

4.1.2 Setting User Permissions

4.1.3 Adding/Deleting User Groups

4.1.4 Setting User Roles/Responsibilities

4.2 Server Administration

4.2.1 Creating Directories

4.2.2 Building Drive Mappings

4.3 System Backup Procedures

4.3.1 Maintenance Schedule

4.3.2 Off-Site Storage

4.3.3 Maintenance of Backup Log

4.4 Printer Support

4.4.1 Maintenance

4.4.2 Print Jobs



QPM #

AQS 200-001-WI

Revision

1


4.5 System Maintenance

4.5.1 Monitoring Performance and System Activity

4.5.2 Installing Programs and Operating System Updates

4.5.3 Maintaining Audit Records

4.5.4 Maintenance Reports

4.6 Security Procedures

4.6.1 Issuing Ids and Passwords

4.6.2 License Agreements

4.7 Network Maintenance

4.7.1 LAN Design

4.7.2 Communications Equipment

4.8 Inventory Management

4.8.1 Maintaining Hardware and Software Configurations

4.8.2 Maintaining Floor Plans

4.8.3 Installing Software and Hardware

4.8.4 Maintaining Lists of Serial Numbers

4.8.5 Maintaining Property Inventory

4.9 Training the Backup Administrator

4.10 Procedures for End-User Support

4.10.1 Escalation Procedures

4.11 Documentation

4.11.1 Troubleshooting Issues

4.12 Database Maintenance

4.12.1 Database User/Group Access

4.12.2 Adding/Deleting Users to Database

4.12.3 Setting User Permissions for Database

4.12.4 Adding/Deleting Groups for Database

4.12.5 Re-indexing Database

4.12.6 Packing/Compressing Database

4.12.7 Data Entry/Modification/Deletion

4.12.8 Database Reporting



QPM #

AQS 200-001-WI

Revision

1


4.12.9 Database Backup and Restore

4.13 Application Maintenance

4.13.1 Application User/Group Access

4.13.2 Adding/Deleting Application Users

4.13.3 Setting User Application Permissions

4.13.4 Adding/Deleting Application Groups

4.13.5 Procedures to Start and Stop the Application

4.13.6 Application Flow Chart

4.13.7 Description of Major Program or Sub-program Modules



QPM #

AQS 200-001-WI

Revision

1


36 TRAINING PLAN

The Training Plan outlines the objectives, needs, strategy, and curriculum to be addressed when training users on the new or enhanced information system. The plan presents the 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.

Training activities are developed to teach user personnel the use of the system as specified in the training criteria. The AVS IT Training Program Manager should be consulted in the development of the Training Plan. A sample outline is included in this document.

Include the target audiences and topics on which training must be conducted on the list of training needs. Include in the training strategy how the topics will be addressed. This information includes the format of the training program, the list of topics to be covered, materials, time, space requirements, and proposed schedules. Discuss QA in terms of testing, course evaluation, feedback, and course modification/enhancement.

36.1. INTRODUCTIONThis section provides a management summary of the entire plan. It is not required to provide information in this section if the descriptions provided in the subsequent sections are sufficient.

36.1.1. Background and ScopeThis section provides a brief description of the project from a management perspective. It identifies the system, its purpose, and its intended users. This section also provides a high-level summary of the Training Plan and its scope.

36.1.2. Points of ContactThis section provides the organization name (code) and title of key points of contact for system development. It includes such points of contact as the Project Manager, Program Manager, QA Manager, Security Manager, Training Coordinator, and Training representative, as appropriate.

36.1.3. Document OrganizationThe organization of the Training Plan is described in this section.

36.1.4. Project ReferencesThis section provides a bibliography of key project references and deliverables that have been produced before this point. For example, these references might include the Project Plan, FRD, Test Plan, Implementation Plan, Conversion Plan, and Systems Design Documents.

36.1.5. Security and the Privacy ActIf applicable, this section provides a brief discussion of the system's security controls and the need for security and protection of sensitive AVS data. If the system handles sensitive or Privacy Act information, information should be included about labeling system outputs as sensitive or Privacy Act-related. In addition, if the system is protected by the Privacy Act, include



QPM #

AQS 200-001-WI

Revision

1


a notification of the Privacy Act's civil and criminal penalties for unauthorized use and disclosure of system data.

36.1.6. GlossaryThis section is a glossary of all terms and abbreviations used in the plan. If it is several pages in length, it may be placed as an appendix.

36.2. REQUIREMENTS TRACEABILITYIf possible, this section presents a traceability matrix that lists user requirements as documented in the FRD and traces how they are addressed in such documents as the Systems Design Document, Test Plan, and Training Plan. Cross-reference the user requirements and training needs in the appropriate sections of the Training Plan.

The requirements matrix may be broken into segments, if appropriate. For example, provide a separate matrix of the Training Plan sections that trace to particular sections in the Systems Design Document, FRD, and the SOW.

36.3. INSTRUCTIONAL ANALYSIS

36.3.1. Development ApproachThis section discusses the approach used to develop the course curriculum and ensure quality training products. This description includes the methodology used to analyze training requirements in terms of performance objectives and to develop course objectives that ensure appropriate instruction for each target group. The topics or subjects on which the training must be conducted should be listed or identified.

36.3.2. Issues and RecommendationsAny current and foreseeable issues surrounding training are included in this section. Recommendations for resolving each issue and constraints and limitations should also be listed.

36.3.3. Needs and Skills AnalysisThis section describes the target audiences for courses to be developed. Target audiences include technical professionals, user professionals, data entry clerks, clerical staff members, ADP and non-ADP managers, and executives. The tasks that must be taught to meet objectives successfully and the skills that must be learned to accomplish those tasks are described in this section. A matrix may be used to provide this information. Also in this section, the training needs for each target audience are discussed. If appropriate, this section should discuss needs and courses in terms of staff location groupings, such headquarters and field offices.

36.4. INSTRUCTIONAL METHODS

36.4.1. Training MethodologyThis section describes the training methods to be used in the proposed courses; these methods should relate to the needs and skills identified in Section 3.3, Needs and Skills Analysis, and should take into account such factors as course objectives, the target audience for a particular course, media characteristics, training setting criteria, and costs. The materials for the chosen training approach, such as course outlines, audiovisual aids, instructor and student guides,



QPM #

AQS 200-001-WI

Revision

1


student workbooks, examinations, and reference manuals should be listed or discussed in this section. Sample formats of materials can be included in an appendix, if desired.

36.4.2. Training DatabaseIf applicable, this section identifies and discusses the training database and how it will be used during computer systems training. It discusses the simulated production data related to various training scenarios and cases developed for instructional purposes. This section also explains how the training database will be developed. If this section is not applicable to the system involved, indicate "Not applicable."

36.4.3. Testing and EvaluationThis section describes methods used to establish and maintain QA over the curriculum development process. This description should include methods used to test and evaluate training effectiveness, evaluate student progress and performance, and apply feedback to modify or enhance the course materials and structure.

One source of feedback could be a course- or module-specific course or instructor evaluation form. This form should gather trainee reactions on the following topics: scope and relevance of course or module, appropriateness of objectives, usefulness of assignments and materials, effectiveness of course training materials, stronger and weaker features of the course, adequacy of the facilities, timing or length of the course or module, effectiveness of the instructor(s), and participant suggestions and comments.

36.5. TRAINING RESOURCES

36.5.1. Course AdministrationThis section describes the methods used to administer the training program, including procedures for class enrollment, student release, reporting of academic progress, course completion and certification, monitoring of the training program, training records management, and security, as required.

36.5.2. Resources and FacilitiesThis section describes the resources required by both instructors and students for the training, including classroom, training, and laboratory facilities; equipment such as an overhead projector, projection screen, flipchart or visual aids panel with markers, and computer and printer workstations; and materials such as memo pads and pencils, diskettes, viewgraphs, and slides. Information contained in this section can be generic in nature and can apply to all courses. Specific course information and special needs may be itemized here as well or, if many different courses are involved, in Section 6, Training Curriculum.

36.5.3. SchedulesThis section presents a schedule for implementing the training strategy and indicating responsible parties. Included are key tasks to be completed, such as when to set up training facilities and schedule participants; other activities essential to training; and dates on which those tasks and activities must be finished. This section provides an overview of tasks; deliverables, such as approach and evaluation forms; scheduled versus actual milestones; and



QPM #

AQS 200-001-WI

Revision

1


estimated efforts, such as the work plan. In the final version of the Training Plan, actual course schedules by location should be included.

36.5.4. Future TrainingThis section discusses scheduled training modifications and improvements. This information can include periodic updating of course contents, planned modifications to training environments, retraining of employees, and other predicted changes. Indicate procedures for requesting and developing additional training.

36.6. TRAINING CURRICULUMThis section provides descriptions of the components that make up each course. If a large number of courses or modules are described, place these descriptions in an appendix. Subsections of this section, if any, should be created for each course.

Each course may comprise one or more modules. A course description should be developed for each module. At a minimum, each course description should include the course/module name; the length of time the course/module will take; the expected class size (minimum, maximum, optimal); the target audience; course objectives; module content/syllabus; specific training resources required, such as devices, aids, equipment, materials, and media to be used; and any special student prerequisites. The course description could also include information on instructor-to-student ratio, total number of students to be trained, estimated number of classes, location of classes, and testing methods.

36.7. TRAINING PLAN OUTLINECover Page

Table of Contents

1.0 Introduction

1.1 Background and Scope


1.3 Document Organization


1.5 Security and the Privacy Act

1.6 Glossary

2.0 Requirements Traceability (optional)

3.0 Instructional Analysis

3.1 Development Approach

3.2 Issues and Recommendations

3.3 Needs and Skills Analysis

4.0 Instructional Methods



QPM #

AQS 200-001-WI

Revision

1


4.1 Training Methodology

4.2 Training Database

4.3 testing and Evaluation

5.0 Training Resources

5.1 Course Administration

5.2 Resources and Facilities

5.3 Schedules

5.4 Future Training

6.0 Training Curriculum



QPM #

AQS 200-001-WI

Revision

1


37 USER MANUAL

37.1. INTRODUCTIONThe User Manual contains all essential information for the user to make full use of the information system. This manual includes a description of the system functions and capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use. Use graphics where possible in this manual. The manual format may be altered if another format is more suitable for the particular project.

37.1.1. Purpose and ScopeThis section provides a description of the purpose and scope of the User Manual.

37.1.2. OrganizationThis section describes the organization of the User Manual.

37.1.3. Points of ContactThis section identifies the organization codes and staff (and alternates if appropriate) who may assist the system user. If a help desk facility or telephone assistance organization exists, describe it in this section.

37.1.4. Project ReferencesThis section provides a bibliography of key project references and deliverables that have been produced prior to this point in the system development process. References might include the QA Plan, CM Plan, FRD, or Systems Design Document.

37.1.5. Primary Business FunctionsThis section discusses the business perspective of the user's primary responsibilities and tasks as they are supported by the system. Introduce the business functions so that the focus may rest on the systematic steps to support the business functions in later sections.

37.1.6. GlossaryThis section provides a glossary of all terms and abbreviations used in the manual. If the glossary is several pages or more in length, it may be placed as an appendix.

37.2. SYSTEM CAPABILITIESThis section provides a brief overview of the system and its capabilities.

37.2.1. PurposeThis section describes the purpose of the application system.

37.2.2. General DescriptionThis section provides an overview of the system's capabilities, functions, and operation, including the specific high-level functions performed by the system. Use graphics and tables, if appropriate.



QPM #

AQS 200-001-WI

Revision

1


37.2.3. Privacy Act ConsiderationsIf the system is protected by the Privacy Act, include this notification of the Privacy Act's "Civil and Criminal Penalties" found in U.S. Code Section 552a, Records Maintained on Individuals, concerning the unauthorized use and disclosure of system data:

Criminal Penalties - (1) Any officer or employee of an agency, who by virtue of employment or official position, has possession of, or access to, agency records which contain individually identifiable information, the disclosure of which is prohibited by U.S. Code Section 552a or by rules or regulations established thereunder, and who knowing that disclosure of the specific material is so prohibited, willfully discloses the material in any manner to any person or agency not entitled to receive it, shall be guilty of a misdemeanor and fined not more than $5,000. (2) Any officer or employee of any agency who willfully maintains a system of records without meeting the requirement to publish a notice in the Federal Register regarding the existence and character of the system of records, shall be guilty of a misdemeanor and fined not more than $5,000. (3) Any person who knowingly and willfully requests or obtains any record concerning an individual from an agency under false pretenses shall be guilty of a misdemeanor and fined not more than $5,000.

37.3. DESCRIPTION OF SYSTEM FUNCTIONSThis section describes each specific function of the system. In this high-level section, describe any conventions to be used in the associated subsections.

Each of the subsequent sections should be repeated as often as necessary to describe each function within the system. The term "Function X" in the subsection title is replaced with the name of the function.

37.3.1. Function X TitleThis section provides the title of the specific system function.

37.3.2. Detailed Description of FunctionThis section provides a description of each function. Include the following, as appropriate:

Purpose and uses of the function Initialization of the function, if applicable Execution options associated with this function Description of function inputs Description of expected outputs and results Relationship to other functions Summary of function operation

37.3.3. Preparation of Function InputsThis section defines required inputs. These inputs should include the basic data required to operate the system. The definition of the inputs includes the following:

Title of each inputUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


Description of the inputs, including graphic depictions of display screens Purpose and use of the inputs Input medium Limitations and restrictions Format and content on inputs, and a descriptive table of all allowable values for

the inputs Sequencing of inputs Special instructions Relationship of inputs to outputs Examples

37.3.4. ResultsThis section describes expected results of the function. Include the following in the description, as applicable:

Description of results, using graphics, text, and tables Form in which the results will appear Output form and content Report generation Instructions on the use of outputs Restrictions on the use of outputs, such as those mandated by Privacy Act and

Computer Security Act restrictions Relationship of outputs to inputs Function-specific error messages Function-specific or context-sensitive help messages associated with this

function Examples

37.4. OPERATING INSTRUCTIONSThis section provides detailed, step-by-step system operating instructions.

37.4.1. Initiate OperationThis section contains procedures for system logon and system initialization to a known point, such as a system main menu screen. This initialization procedure should describe how to establish the required mode of operation and set any initial parameters required for operation. Software installation procedures should be included if the software is distributed on diskette and should be downloaded before each use.

37.4.2. Maintain OperationThis section defines procedures to maintain the operation of the software where user intervention is required.



QPM #

AQS 200-001-WI

Revision

1


37.4.3. Terminate and Restart OperationsThis section defines procedures for normal and unscheduled termination of the system operations and should define how to restart the system.

37.5. ERROR HANDLINGThis section should address error message and help facilities. Additional information and subsections may be added as necessary. Included in this section should be a list of all possible error messages, including the following:

Any numeric error codes associated with the error message A description of the meaning of the error message A discussion of how to resolve the error

37.5.1. Help FacilitiesThis section describes any resident help software or any Service or contractor help desk facility that the user can contact for error resolution. Help desk telephone numbers should be included.

37.6. USER MANUAL OUTLINECover Page

Table of Contents

1.0 Introduction


1.2 Organization



1.5 Primary Business Functions

1.6 Glossary

2.0 System Capabilities

2.1 Purpose

2.2 General Description

2.3 Privacy Act Considerations

3.0 Description of System Functions

3.1 Function X Title

3.2 Detailed Description of Function

3.3 Preparation of Function inputs

3.4 Results

4.0 Operating InstructionsUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


4.1 Initiate Operation

4.2 Maintain Operation

4.3 Terminate and Restart Operations

5.0 Error Handling

6.0 Help Facilities



QPM #

AQS 200-001-WI

Revision

1


38 SOFTWARE DEVELOPMENT DOCUMENT

38.1. 1.0 INTRODUCTIONThe software development document contains all preparations pertaining to the development of each unit or module, including the software, test cases, test results, approvals, and any other items that will help to explain the functionality of the software. The document is dynamic and is maintained by the system development team and should be constantly updated as the system's development progresses. The software development folder should include the following information for each unit:

Description of the unit's functionality in narrative format Description of development methodologies used Requirements in the functional requirements document allocated to this unit or

module Completed traceability matrix displaying the unit's test cases satisfying the

functional requirements in the test plan Source code listing Controlled libraries/directories/tables All data necessary to conduct unit testing Unit test results and analysis System Technical Lead sign off for design walk-through, approval of code, and

completion of each unit Completed Software Development Document Check-Off sheet (attached)

38.2. 2.0 ROLES AND RESPONSIBILITIESThe team members have the following roles and responsibilities:

The application developer assigned the primary responsibility for the module or unit creates a file folder for the unit, labels it according to the name of the unit, and places it in the appropriate place in the project team file cabinet.

The application developer(s) add copies of the indicated documentation to the folder as they are created.

The project QA representative reviews the contents of the folder for completeness, and points out discrepancies to the developer assigned primary responsibility for the module or unit.

The developer assigned primary responsibility for the module or unit completes the Software Development Document Check-Off sheet and arranges for the System Technical Lead review and approval when needed.

The folder is available to all project team members for review, but if removed from the file cabinet, it must be replaced with a check-out card indicating who checked it out, when, and where it will be located.



QPM #

AQS 200-001-WI

Revision

1


38.2.1. ProcessFill out the following sections of the Check-Off sheet:

Requirements: Place a checkmark to the left of each question when it is determined that the answer is "Yes." This indicates that there is a match between the requirements traceability matrix and the requirements addressed by this module.

Functionality: Place a checkmark to the left of each question when it is determined that the answer is "Yes." This indicates that a complete narrative description of the module's functionality is available, that a walk-through of the module's design was conducted before the start of the programming, and that System Technical Lead approval was granted to begin the programming work.

Source Code: Place a checkmark to the left of the question when it is determined that a current copy of the program source listing has been placed in the folder.

Libraries, Directories, and Tables: Place a checkmark to the left of the question when it is determined that the program source code and copybook libraries and associated electronic tables are identified, and copies, as needed are in the folder.

Development Methodologies: Place a checkmark to the left of the question when it is determined that the programming methodology descriptions are all included in the folder.

Test Data: Place a checkmark to the left of each question when it is determined that the location and identity of all needed unit test data are included in the folder.

Test Analysis: Place a checkmark to the left of the question when it is determined that the unit has been thoroughly tested.

Sign-Off: Date and sign the certification for completion of coding and unit testing for the module.

38.3. SOFTWARE DEVELOPMENT FOLDER CHECK-OFF SHEETREQUIREMENTS

Has each requirement in the functional requirements document allocated to this unit been identified using the traceability matrix?

Have derived requirements found during the development of this unit been identified, justified, and put in the functional requirements document?

FUNCTIONALITY

Is the functionality of this unit fully described?

Is the description in narrative form?

Was a design walk-through conducted?

Was permission granted to begin programming?

SOURCE CODE

Is the source code listing of the unit included in this folder?

LIBRARIES, DIRECTORIES, AND TABLESUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


Are all coded entities included in the folder?

DEVELOPMENT METHODOLOGIES

Are all development methodologies for the development effort described in the folder?

TEST DATA

Are all data necessary to conduct testing referenced in this folder?

TEST ANALYSIS

Was the unit thoroughly tested and were all logical paths verified?

SYSTEM DEVELOPER

I certify that this software development document is complete, the unit ______ defined in this folder has successfully completed development and unit testing, and the unit is ready to be baselined and integrated into the system

Date ________________ System Developer: __________________

System Technical Lead Initials: __________



QPM #

AQS 200-001-WI

Revision

1


39 INTEGRATION DOCUMENT

The integration document defines the activities necessary to integrate the software units and software components into the software item. The integration document contains an overview of the system, a brief description of the major tasks involved in the integration, the overall resources needed to support the integration effort. The plan is developed during the Development Phase and is updated during the Integration and Test Phase; the final version is provided in the Implementation Phase.

39.1. INTRODUCTIONThis section provides an overview of the information system and includes any additional information that may be appropriate.

39.1.1. Purpose and ScopeThis section describes the purpose and scope of the Integration Document. Reference the system name and identify information about the system to be integrated.

39.1.2. System OverviewThis section provides a brief overview of the system to be integrated, including a description of the system and its organization. Describe the environment/infrastructure and how this unit or system will integrate into it. Include any risk involved and the mitigating procedures to reduce or eliminate that risk.

39.1.2.1. System Description

This section provides an overview of the processes the system is intended to support. If the system is a database or an information system, provide a general discussion of the description of the type of data maintained and the operational sources and uses of those data. Also include all interfaces to other units or systems.

39.1.2.2. Unit Description

This section provides an overview of the processes the unit (or module) is intended to support. If more than one unit is being integrated, provide descriptions of each unit in this section.

39.1.3. Project ReferencesThis section provides key project references and deliverables that have been produced before this point in the project development. Provide policies or laws that give rise to the need for this plan. For example, these references might include the Project Management Plan, Acquisition Plan, FRD, Test Plan, Conversion Plan, and Systems Design Document.

39.1.4. GlossaryProvide a glossary of all terms and abbreviations used in the document. If it is several pages in length, it may be placed in an appendix.



QPM #

AQS 200-001-WI

Revision

1


39.2. MANAGEMENT OVERVIEWThe subsequent sections provide a brief description of the integration and major tasks involved in this section.

39.2.1. Description of IntegrationThis section provides a brief description of the system units and the integration approach.

39.2.2. ResponsibilitiesIn this section, identify the System Proponent, the name of the responsible or issuing organization, and titles and telephone numbers of the staff who serve as points of contact for the system integration. It should also include who has approval authority for each unit of the system. If this activity is contracted out, list the names and phone numbers of the contractor responsible for the development and integration.

39.2.3. Activities and TasksThis section provides a brief description of each major task required for the integration of the system. Also include a schedule for when these tasks are expected to be completed. Add as many subsections as necessary to this section to describe all the major tasks adequately. Include the following information for the description of each major task, if appropriate:

What the task will accomplish Resources required to accomplish the task Key person(s) responsible for the task Criteria for successful completion of the task

Examples of major tasks are the following:

Providing overall planning and coordination for the integration Providing appropriate training for personnel Providing appropriate documentation on each unit for integration Providing audit or review reports Documented software unit and database Establish software requirements Establish test procedures Conduct unit testing Conduct qualification testing Integrate units into system

39.3. INTEGRATION SUPPORTThis section describes the support software, materials, equipment, and facilities required for the integration, as well as the personnel requirements and training necessary for the integration.



QPM #

AQS 200-001-WI

Revision

1


39.3.1. Resources and their AllocationIn this section, list all support software, materials, equipment, and facilities required for the integration. Describe the test environment and any resources needed. Describe the number of personnel needed and an estimate of the costs for them.

39.3.2. TrainingThis section addresses the training, if any, necessary to prepare for the integration and maintenance of the system; it does not address user training, which is the subject of the Training Plan. If contractors are performing the integration functions and activities, this may not be necessary. If, however, AVS staff is performing these activities, some training might be needed. List the course(s) needed by title, instructor and cost.

39.3.3. TestingIn this section, list all the test requirements for each unit. If more than one unit is being tested, include a description for each unit. Include the descriptions of the data included, procedures for testing, who is responsible for the testing and a schedule. This could be accomplished in one plan or several depending on the complexity of the unit being tested.

39.3.3.1. Change procedures and history

Include all changes made during the unit testing. This information should be included in the Configuration Management Plan and updated during the Development Phase.

39.4. INTEGRATION DOCUMENT OUTLINECover Page

Table of Contents

1.0 Introduction


1.2 System Overview

1.2.1 System Description

1.2.2 Unit Description


1.4 Glossary

2.0 Management Overview

2.1 Description of Integration

2.2 Responsibilities

2.3 Activities and Tasks

3.0 Integration Support

3.1 Resources and their Allocation



QPM #

AQS 200-001-WI

Revision

1


3.2 Training

3.3 Testing

3.4 Change procedures and history



QPM #

AQS 200-001-WI

Revision

1


40 TEST ANALYSIS REPORT

The Test Analysis Report documents software testing - unit/module, subsystem integration, system, user acceptance, and security - as defined in the test plan. The Test Analysis Report records results of the tests, presents the capabilities and deficiencies for review, and provides a means of assessing software progression to the next stage of development or testing. Results of each type of test are added to the software development document for the module or system being tested. Reports are created as required in the remaining phases. The set of Test Analysis Reports provides a basis for assigning responsibility for deficiency correction and follow up, and for preparation of a statement of project completion.

Test Problem Report forms are generated as required and are attached to the Test Analysis Reports during testing at the integration level and higher. The disposition of problems found, starting with integration testing, will be traced and reported under configuration control.

40.1. PURPOSEThis section should present a clear, concise statement of the purpose for the Test Analysis Report.

40.2. SCOPEThis section identifies the software application system tested and the test(s) conducted covered by this Test Analysis Report. The report summarizes the results of tests already conducted and identifies testing that remains to be conducted. Provide a brief summary of the project objectives, and identify the System Proponent and users.

40.3. REFERENCE DOCUMENTSThis section provides a bibliography of key project references and deliverables applicable to system software testing. These references might include the FRD, User Manual, Operations Manual, Maintenance Manual, Test Plan, and prior Test Analysis Reports.

40.3.1. SecurityThis section describes any security considerations associated with the system or module being tested, the test analysis, and the data begin handled - such as confidentiality requirements, audit trials, access control, and recoverability. If this Test Analysis Report is not documenting the formal security test, also summarize the security capabilities included in the system or module test and itemize the specific security deficiencies detected while conducting the test.

The results of specific tests, findings, deficiency analysis, and recommendations will be discussed in the subsequent sections. Reference those portions of this document that specifically address system security issues. If no deficiencies were detected during the system or module test, state this fact.

40.3.2. GlossaryThis section defines all terms and provides a list of abbreviations used in the Test Analysis Report. If the list is several pages in length, it may be placed as an appendix.



QPM #

AQS 200-001-WI

Revision

1


40.4. TEST ANALYSISThis section describes the results of each test performed. Tests at each level should include verification of access control and system standards, functionality, and error processes. Repeat the subsections of this section for each test performed.

40.4.1. Test NameThe test performed for the specified unit, module, subsystem, or system is discussed in this section. For each test, provide the subsequent sections.

40.4.1.1. System Function

A high-level description of the function tested and a description of system capabilities designed to satisfy these functions are contained in this section. Each system function should be described separately.

40.4.1.2. Functional Capability

This section evaluates the performance of each function demonstrated in the test. This section also assesses the manner in which the test environment may be different from the operational environment and the effect of this difference on functional capabilities.

40.4.1.3. Performance Capability

This section quantitatively compares the software performance characteristics with the criteria stated in the test plan. The comparison should identify deficiencies, limitations, and constraints detected for each function during testing. If appropriate, a test history or log can be included as an appendix.

40.5. SOFTWARE AND HARDWARE REQUIREMENTS FINDINGSThis section summarizes the test results, organized according to the numbered requirements listed in the Traceability section of the test plan. Each numbered requirement should be described in a separate section. Repeat the subsections of this section for each numbered requirement covered by the test plan.

40.5.1. Requirement Number and NameThe requirement number provided in the title to this section is the number from the requirements traceability matrix in the test plan and the name provided is the requirement's short name.

40.5.1.1. Findings

This subsection briefly describes the requirement, including the software and hardware capabilities, and states the findings from one or more tests.

40.5.1.2. Limitations

This subsection describes the range of data values tested, including dynamic and static data, for this requirement and identifies deficiencies, limitations, and constraints detected in the software and hardware during the testing.



QPM #

AQS 200-001-WI

Revision

1


40.6. SUMMARY AND CONCLUSIONS40.6.1. Demonstrated CapabilitiesThis section provides an overview and summary analysis of the testing program. Describe the overall capabilities and deficiencies of the testing software module or system. Where tests were intended to demonstrate one or more specific performance requirements, findings should be presented that compare the test results with the performance requirements. Include an assessment of any differences in the test environment versus the operational environment that may have had an effect on the demonstrated capabilities. Provide a statement, based on the results of the system or module test, concerning the adequacy of the system or module to meet overall security requirements.

40.6.2. System DeficienciesThis section describes test results showing software deficiencies. Identify all problems by name and number when placed under configuration control. Describe the cumulative or overall effect of all detected deficiencies on the system of module.

40.6.3. System RefinementsThis section itemizes any indicated improvements in system design or operation based on the results of the test period. Accompanying each improvement or enhancement suggested should be a discussion of the added capability it provides and the effect on the system design. The improvements should be indicated by name and requirement number when placed under configuration control.

40.6.4. Recommendations and EstimatesThis section provides a statement describing the overall readiness for system implementation. For each deficiency, address the effect on system performance and design. Include any estimates of time and effort required for correction of each deficiency and any recommendations on the following:

The urgency of each correction Parties responsible for corrections Recommended solution or approach to correcting deficiencies

40.6.5. Test Problem ReportThis section contains copies of the test Problem Reports related to the deficiencies found in the test results. The Test Problem Report will vary according to the information system development project, its scope and complexity, etc. Test Problem Report forms are generated as required and are attached to the Test Analysis Reports during testing at the integration level and higher. The disposition of problems found, starting with integration testing, should be tracked and reported under configuration control.



QPM #

AQS 200-001-WI

Revision

1


40.6.6. Test Analysis Approval Determination FormThis section contains one copy of the Test Analysis Approval Determination form. This form briefly summarizes the perceived readiness for migration of the software. In the case of a User Acceptance Test, it serves as the user's recommendation for migration to production.

40.7. TEST ANALYSIS REPORT OUTLINECover Page

Table of Contents

1.0 Purpose

2.0 Scope


3.1 Security

3.2 Glossary

4.0 Test Analysis

4.1 Test Name (repeat for each test)

4.1.1 System Functions

4.1.2 Functional Capability

4.1.3 Performance Capability

5.0 Software and Hardware Requirements Findings

5.1 Requirement Number and Name (repeat for each test)

5.1.1 Findings

5.1.2 Limitations

6.0 Summary and Conclusions

6.1 Demonstrated Capabilities

6.2 System Deficiencies

6.3 System Refinements

6.4 Recommendations and Estimates

6.5 Test Problem Report

6.6 Test Analysis Approval Determination Form



QPM #

AQS 200-001-WI

Revision

1


41 TEST ANALYSIS APPROVAL DETERMINATION

The Test Analysis Approval Determination (TAAD) form is completed immediately following the completion of testing (for all testing levels above the Integration test) for software to be delivered to AVS. This form briefly summarizes the perceived readiness by the test engineer for delivery of the software to the next test phase. In the case of User Acceptance Test, it serves as the use's recommendation for fielding the software release or migration to production. The TAAD form for non-mainframe applications and mainframe migration is attached.

The TAAD is to be initiated by the T&E organization and addressed to the AVS Manager. The form is signed by the responsible test engineer and supervisor. The AVS Manager signs the form signifying receipt from the test organization and is then attached to the test analysis report (see Appendix C-28 Test Analysis Report).

41.1. TEST ANALYSIS APPROVAL DETERMINATION OUTLINE (NON-MAINFRAMES )

DATE: _________________

FROM: _________________

TO: __________________

We have reviewed the test results for the following application release:

TITLE:

We recommend:

( ) a. Full acceptance. The Test Analysis Report describes any problems encountered, which are now corrected.

( ) b. Full implementation with modifications implemented in a future release. The Test Analysis Report describes the outstanding discrepancies and the potential impact of these items to the End User.

( ) c. Partial implementation. The Test Analysis Report details the recommended implementation limitations, and describes the impact and expected results of this alternative.

( ) d. Rejection. The Test Analysis Report describes the reasons.

SIGNATURE: ___________________ ___________________

Test Engineer Date

SIGNATURE: ____________________ ____________________

T&E Leader Date

41.2. TEST ANALYSIS APPROVAL DETERMINATION (FOR MAINFRAMES)DATE: _______________

FROM: _______________



QPM #

AQS 200-001-WI

Revision

1


TO: __________________

We have reviewed the test results for the following application migration:

TITLE:

We Recommend:

( ) a. Migration to Production. The Test Analysis Report describes any problems encountered, which are now corrected.

( ) b. Migration to Production with modifications migrated in a future release. The Test Analysis Report describes the outstanding discrepancies and the potential impact of these items to the End User.

( ) c. Partial migration. The Test Analysis Report details the recommended migration limitations, and describes the impact and expected results of this alternative.

( ) d. Rejection. The Test Analysis Report describes the reasons.

SIGNATURE: ____________________ _________________

Test Engineer Date

SIGNATURE: ___________________ _________________

T&E Leader Date



QPM #

AQS 200-001-WI

Revision

1


42 TEST PROBLEM REPORTS

The Test Problem Report form (see attached) is generated as required and is attached to the Test Analysis Report (Section 41) during testing at the integration level and higher. The disposition of problems found, starting with integration testing, will be tracked and reported under configuration control.

Generate multiple copies of Test Problem Reports related to the deficiencies found in the test results, and track problem(s) until they are resolved. The Test Problem Report will vary according to the information system development project, its scope, and its complexity.

42.1. TEST PROBLEM REPORT OUTLINETO: __________________

FROM: _________________

PREPARER/CONTACT: __________________ PHONE: ______________

PROGRAM BEING TESTED: _________________

Description OF TEST PROBLEM

A. Expected Results

B. Actual Results

DISPOSITION OF PROBLEM

Action Taken and Date Corrected

Risk Impact if Problem Not Corrected

Changes Required for Existing Documentation

SIGNATURES _____________________ _____________________

Project Manager System Developer

______________________ _____________________

Date



QPM #

AQS 200-001-WI

Revision

1


43 CHANGE IMPLEMENTATION NOTICE

For the _________________ System

This notice is to request a change for the:

Application Name: ____________________________________

Located at: ____________________________________

The change requested is as follows:

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

This office rates the urgency of this request as:

____ Critical (Address ASAP, possibly with a patch)

____ Important (Address in the next version release)

____ Nice to have (Not necessary to operation, but would improve the system)

Change implementation notice number (CIN): ________________________

Signed: ________________________ Date: _________________

Local System Administrator

Signed: ________________________ Date: _________________

Suggesting End User



QPM #

AQS 200-001-WI

Revision

1


44 VERSION DESCRIPTION DOCUMENT

44.1. INTRODUCTIONThe Version Description Document (VDD) is the primary configuration control document used to track and control versions of software to be released to the operational environment. It is a summary of the features and contents for the software build. It identifies and describes the version of the software CI being delivered to AVS, including all changes to the software CI since the last VDD was issued. Every unique release of the software (including the initial release) shall be described by a VDD. If multiple forms of the software CI are released at approximately the same time (such as, to different sites) each must have a unique version number and a VDD.

The VDD is part of the software CI product baseline. The VDD, when distributed, should be sent with a cover memo that summarizes, on a single page, the significant changes that are included in the release. This will serve as an executive summary for the details found in the attached VDD. The treatment should be titled, on the cover memo, as Summary of Changes.

44.1.1. Roles and ResponsibilitiesThe following roles and responsibilities apply to the VDD:

The CM representative will prepare the VDD with the help of the project team. Members of the Project Manager's organization will normally prepare Sections

3.5, Adaptation Data, through 3.9, Glossary, appendices, and the Summary of Changes cover memo.

44.1.2. ProcessA VDD is prepared according to the outline at the end of this document, and specific instructions are provided in the subsequent sections.

44.2. SCOPE44.2.1. IdentificationProvide full identification number(s), title(s), and abbreviation(s); and, if applicable, provide the version number(s) and release number(s). Identify the intended recipients of the VDD.

44.2.2. ApplicabilityIdentify the intended recipients of the software release and the operating system to be used.

44.2.3. System OverviewProved a brief statement of the purpose of the system and the environments to which this document applies. Describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify current and planned operating sites; and list other relevant documents.



QPM #

AQS 200-001-WI

Revision

1


44.2.4. Documentation OverviewSummarize the purpose and contents of this document and describe any security or privacy considerations associated with its use.

44.2.5. Points of ContactProvide a list of both INS and performance contractor(s) points of contact involved in this effort.

44.3. REFERENCE DOCUMENTSList the number, title, revision, and date of all documents referenced in or used in the preparation of this VDD. If this VDD is an update to an existing system, list the VDD that this version is replacing as a reference document.

44.4. VERSION DESCRIPTIONSummarize briefly the contents of the ensuing sub-paragraphs (to include materials contained in the release, software components of the subsystem software CI, documents used to establish the configuration of the software CI, and any known problems).

44.4.1. Inventory of Materials ReleasedList by CM numbers, titles, abbreviations, dates, version numbers, and release numbers (as applicable), all physical media (for example, listings, tapes, disks) and associated documentation that make up the software version being released. Include applicable security and privacy considerations for these items, safeguards for handling them, such as concerns for static and magnetic fields, and instructions and restrictions regarding duplication and license provisions.

44.4.2. Inventory of Software ContentsList by identifying numbers, titles, abbreviations, dates, version numbers, and release numbers (as applicable), all computer files that make up the software version being released. Any applicable security and privacy considerations should be included.

44.4.3. Changes InstalledList all changes incorporated into the software version since the previous version. Identify, as applicable, System Change Requests (SCRs) and migration forms associated with each change and the effects, if any, of each change on system operation and on interfaces with other hardware and software. (This section does not apply to the initial software version.)

44.4.4. Interface CompatibilityList and describe any other systems or CIs affected by the change(s) incorporated in the current version, if applicable.

44.4.5. Adaptation DataIdentify and reference all unique-to-site data contained in the software version. For software versions after the first, describe changes made to the adaptation data.



QPM #

AQS 200-001-WI

Revision

1


44.4.6. Bibliography of Reference DocumentsList (by identifying numbers, titles, abbreviations, dates, version numbers, and release numbers as applicable), all documents that establish the current version of the software CI.

44.4.7. Installation InstructionsProvide or reference the following information, as applicable:

Instructions for installing the software version, including instructions for deletion of old versions

Identification of other changes that have to be installed for this version to be used, including site-unique adaptation data not included in the software version

Security, privacy, or safety precautions relevant to the installation Procedures for determining if the version has been installed properly A point of contact to be consulted if there are problems or questions with the

installation

44.4.8. Possible Problems and Known ErrorsIdentify any possible problems or known errors with the software version at the time of release, any steps being taken to resolve the problems or errors, and instructions (either directly or by reference) for recognizing, avoiding, correcting, or otherwise handling each one. The information presented will be appropriate to the intended recipient of the VDD (for example, a user agency may need advice on avoiding errors, a support agency on correcting them).

44.4.9. GlossaryInclude an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document. Also provide a list of any terms and definitions needed to understand this document.

44.5. APPENDICESAppendices may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data, etc.). As applicable, each appendix will be referenced in the main body of the document where the data would normally have been provided. Appendices will be lettered alphabetically (A, B, etc.), and the pages will be numbered A-1, A-2, etc.

44.6. VERSION DESCRIPTION DOCUMENT OUTLINECover Page

Table of Contents

1.0 Scope

1.1 Identification

1.2 Applicability

1.3 System Overview

1.4 Documentation OverviewUNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1




3.0 Version Description

3.1 Inventory of Materials Released

3.2 Inventory of Software Contents

3.3 Changes Installed

3.4 Interface Compatibility

3.5 Adaptation Data

3.6 Bibliography of Reference Documents

3.7 Installation Instructions

3.8 Possible Problems and Known Errors

3.9 Glossary

4.0 Appendices

44.7. VERSION DESCRIPTION DOCUMENT CONTENTSFor the _________________ System

This is to document the following changes contained in version _____ of the:

Application Name: ____________________________________

Located at: ____________________________________

The changes are as follows:

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

This version change is in response to:

____ Change implementation notice number (s) ______________________

____ User group meetings



QPM #

AQS 200-001-WI

Revision

1


____ Change in technology

____ Other ___________________________________________________

Signed: ________________________ Date: _________________

Chief Information Officer

Signed: ________________________ Date: _________________

Application Project Manager

Signed: ________________________ Date: _________________

Program Office Manager



QPM #

AQS 200-001-WI

Revision

1


45 POST-IMPLEMENTATION REVIEW REPORT

The Post-Implementation Review is used to evaluate the effectiveness of the system development after the system has been in production for a period of time (normally 6 months). The objectives are to determine if the system does what it is designed to do: Does it support the user as required in an effective and efficient manner? The review should assess how successful the system is in terms of functionality, performance, and cost versus benefits, as well as assess the effectiveness of the life-cycle development activities that produced the system. The review results can be used to strengthen the system as well as system development procedures.

The review is scheduled to follow the release of a system or system revision by an appropriate amount of time to allow determination of the effectiveness of the system. A representative from the functional development group or other member of the major user organization participates in the review. The System Proponent ensures that all documentation and all personnel needed to participate in the review are accessible.

The reviewer and an assigned team collect the information needed for the Post-Implementation Review by interviewing end users and their managers, system administrators, and computer operations personnel. The report is then prepared and provided to the user organization that requested it and the information systems organization, which may jointly use the findings to initiate other actions.

The Post-Implementation Review is a free-form report, and not all sections are relevant or necessary to the final product. A description of the Post-Implementation Review Report is attached

45.1. INTRODUCTION45.1.1. Project IdentificationProvide the identifying information associated with the project, including the applicable project control code, system acronym, and system title.

45.1.2. System ProponentProvide the name of the System Proponent.

45.1.3. History of the SystemBriefly describe the system's history and predecessor, if any. State the mission needs and information requirements, including how the system is expected to help users.

45.1.4. Functional System Description and Data UsageBriefly describe what the system does functionally and how the data are used by the system.

45.2. EVALUATION SUMMARYThe purpose of this section is to provide a summary of the overall adequacy and acceptance of the system.



QPM #

AQS 200-001-WI

Revision

1


45.2.1. General Satisfaction with the SystemDescribe the users' experience with the implemented system. Comments should address the following:

The level of user satisfaction The strengths of the system, including specific areas of success Any problems Frequently used features Infrequently used features Features not used at all Suggested improvements

45.2.2. Current Cost-Benefit JustificationAssess if the system is paying for itself. Base the assessment on the anticipated benefits and costs projected during the System Concept Development phase and revised during the subsequent phases of the systems development life cycle. This section is intended merely to review the costs and benefits and to provide details of costs and benefits in other sections. Comments should address the following:

The extent of the benefits and if they are reported to be less or greater than those projected in the development analysis and functional requirements report

If any difference is permanent or will change over time If the system is or will be cost-justifiable.

45.2.3. Needed Changes or EnhancementsGauge the magnitude of effort needed to change or improve the system. Describe the nature and priority of the suggested changes; more detail will be provided in other sections. Comments should address the following:

The suggested changes The scope of the changes The resource requirements to effect the changes

45.3. ANALYSIS AND IMPLEMENTATIONThe purpose of this section is to gauge the completeness of the functional requirements and implementation according to the study.

45.3.1. Purpose and ObjectivesEvaluate the adequacy of the original definition of purpose and objectives presented in the functional requirements document and if the objectives were achieved during implementation. Evaluate if any objectives have changed or should have changed. Comments should address the following:

Extent to which goals were met



QPM #

AQS 200-001-WI

Revision

1


The level of the objective definition Extent to which objectives were met Possible changes to the objectives

45.3.2. ScopeAnalyze if proper limits were established in the feasibility study and if they were maintained during implementation. Comments should address the following:

Variations from the scope definition as agreed to in the concept development The extent to which the scope was followed Any possible future changes to the scope

45.3.3. BenefitsAnalyze if the benefits anticipated in the concept development and requirements definition analyses were realized. Detail all benefits, quantifiable or nonquantifiable, and any quantifiable resources associated with each. Comments should address the following:

The adequacy of the benefit definition The level of benefits realized The anticipated benefits that can be realized The reason for the variance between planned and realized benefits

45.3.4. Development CostDetermine the adequacy of the development cost estimated and any deviation between the estimated and actual development costs. Comments should address the following:

The adequacy of the original and subsequent cost estimates The actual costs, by type The reasons for any difference between estimated and actual costs

45.3.5. Operating CostAnalyze the adequacy of the operating cost estimates and any deviation between the estimate and the actual operating costs. Summarize the resources required to operate the system. Comments should address the following:

The adequacy of the operating estimates The actual operating costs The difference

45.3.6. TrainingEvaluate if all levels of user training were adequate and timely. Comments should address the following:

The timeliness of the training provided The adequacy of the training



QPM #

AQS 200-001-WI

Revision

1


The appropriateness of the training Identification of additional training needs by job category The ability of the personnel to use the training provided

45.4. OUTPUTSThe purpose of this section is to evaluate the adequacy and usefulness of the outputs from the system. Care must be taken to ensure that all reports are evaluated.

45.4.1. UsefulnessMeasure the extent to which the users need the output of the system. Comments should address identification of the level of need, such as the following:

Utility Absolutely essential Important and highly desirable Interesting-proves what is already known Incomplete-does not provide all the necessary information Unnecessary

Identification of information/reports needed but not currently generated by the system or unable to be obtained

Demonstration of the ability to do without the reports Alternatives for obtaining the information where improvements can be achieved

45.4.2. TimelinessDetermine if output production performance meets user needs. Comments should address the frequency with which output arrives on time, early, and late; and the amount of follow up needed to obtain the output.

45.4.3. Data QualityAssess the need to provide for effective use of shared data to enhance performance and system interoperability. Comments should address data accuracy and data reliability.

45.5. SECURITYThe purpose of this section is to determine if the system provides adequate security of data and programs. In addition to access security, procedures for backup, recovery, and restart should be reviewed.

45.5.1. Data ProtectionDetermine if the security, backup, recovery, and restart capabilities adequately safeguard data, including master, transaction and source. Online systems naturally require special techniques (such as, transaction logging). Comments should address the following:

The adequacy of the security, backup, recovery, and restart procedures The suggested changes



QPM #

AQS 200-001-WI

Revision

1


The effort required to make the changes

45.5.2. Disaster RecoveryDetermine if appropriate files, programs, and procedures are established to enable recovery from a disaster resulting in the loss of data. Comments should address the following:

The adequacy and currency of off site storage procedures The extent that procedures cover the following:

Master data Transaction data Source programs Object programs Documentation (such as, systems, operations, user manuals)

The results of any adequacy-of-recovery test

45.5.3. ControlsEvaluate the adequacy of the controls on the database, source documents, transactions, and outputs of the system. Review each area thoroughly for financial controls and file control counts. Comments should address the following:

The level of controls present in the entire system and on each component (such as, transaction and batch, and file)

The adequacy of the controls, including the strengths and possible areas for improvement

The amount of resources required, if any, to obtain improvements

45.5.4. Audit TrailsReview the ability to trace transactions through the system and the tie-in of the system to itself. Comments should address the following:

The thoroughness of the audit trails The level of improvements necessary, if any The requirements of audit trails as outlined in the trusted criteria-- such as, C2

requirements--if any

45.5.5. Allowed AccessEvaluate the adherence to restriction of access to data. State the desired privacy criteria for the system and then evaluate how the criteria have been followed up to this point. Comments should address the following:

Established privacy criteria Recommended privacy criteria Adherence to and violations of privacy The cost of providing this level of privacy



QPM #

AQS 200-001-WI

Revision

1


The potential effect on individuals if the privacy criteria are not followed

45.6. COMPUTER OPERATIONSThe purpose of this section is to ascertain the current level of operational activities. Although the user point of view is primary to the Post-Implementation Review Report, the computer operations view is also important to investigate.

45.6.1. Control of Work FlowEvaluate the user interface with the data processing organization. Investigate the submittal of source material, the receipt of outputs, and any problems getting work in, through, and out of computer operations. Comments should address the following:

Any problems in accomplishing the work The frequency and extent of the problems Suggested changes The effort required to make the changes

45.6.2. SchedulingDetermine the ability of computer operations to schedule according to user needs and to complete scheduled tasks. Comments should address the following:

Any problems in accomplishing the work The frequency and extent of the problems Suggested changes The effort required to make changes

45.6.3. User InterfaceAnalyze the usability of the system. The transaction throughput and error rate are included in this analysis. Comments should address the following:

Volume of data processed (number of transactions) Number of errors made Frequency of problems with the interface Suggested changes Effort required to make the changes

45.6.4. Computer ProcessingAnalyze computer processing issues and problems. Some areas to review are as follows:

The correct or incorrect use of forms and off line files The adequacy of instructions (such as, forms lineup and proper responses on the

console) The extent of reruns, if any



QPM #

AQS 200-001-WI

Revision

1


45.6.5. Peak LoadsAssess the ability of the system to handle peak loads and to resolve backlogs when they occur. Any offloading that could be helpful should be investigated. Comments should address the following:

The level of user satisfaction The adequacy of the response time (for online systems) The effect of delays on online and/or batch systems Suggested changes The effort required to make the changes

45.7. MAINTENANCE ACTIVITIESThe purpose of this section is to evaluate maintenance activity involving the system.

45.7.1. Activity SummaryProvide a summary of maintenance activity to date. Provide type, number of actions, and scope of changes required. Estimate a projected maintenance workload based on the findings of the review. Discuss the adequacy of maintenance efforts or if major enhancement/revision is required.

45.7.2. Maintenance ReviewReview completed and pending changes to the system. Provide conclusions regarding the benefits to be achieved by completing recommended changes. Provide conclusions about the amount of maintenance required based on activity that has occurred to date.

45.7.3. System MaintenanceDiscuss the system maintenance based on the design, types of changes required, documentation, and knowledge about the system (both user and technical personnel).

45.8. POST-IMPLEMENTATION REVIEW REPORT OUTLINECover Page

Table of Contents

1.0 Introduction

1.1 Project Identification

1.2 Requesting Organization

1.3 History of the System

1.4 Functional System Description and Data Usage

2.0 Evaluation Summary

2.1 General Satisfaction with the System

2.2 Current Cost-Benefit Justification



QPM #

AQS 200-001-WI

Revision

1


2.3 Needed Changes or Enhancements

3.0 Analysis and Implementation

3.1 Purpose and Objectives

3.2 Scope

3.3 Benefits

3.4 Development Cost

3.5 Operating Cost

3.6 Training

4.0 Outputs

4.1 Usefulness

4.2 Timeliness

4.3 Data Quality

5.0 Security

5.1 Data Protection

5.2 Disaster Recovery

5.3 Controls

5.4 Audit Trails

5.5 Allowed Access

6.0 Computer Operations

6.1 Control of Work Flow

6.2 Scheduling

6.3 User Interface

6.4 Computer Processing

6.5 Peak Loads



QPM #

AQS 200-001-WI

Revision

1


46 PERIODIC SYSTEM REVIEW REPORT

The purpose of the Periodic System Review is to assess the system's performance and user satisfaction. This review process occurs repeatedly to ensure that the system is performing cost-effectively and that it continues to meet the functional needs of the user. The report provides a description of the review process, its focus, and results. The report also may be used to document management approvals regarding further enhancements or development of the system under review. Depending on the timing and focus of the review, it may involve investigation of system response time, data base capacity, newer technologies available, business functions, and continued user satisfaction with the system.

46.1. INTRODUCTIONThis section provides a brief description of introductory material in this section. Whenever appropriate, add other information.

46.1.1. PurposeDescribe the purpose of the Periodic System Review Report in this section. Provide the name and identifying information about the system reviewed. Provide the timing of the review to differentiate the Periodic System Review Reports created in the life of a system.

46.1.2. ScopeThis section defines the boundaries of the system review. Because this review may address initial production performance and/or continued user satisfaction with the system, describe the specific aspects of the review conducted.

46.1.3. Project ReferencesThis section provides a bibliography of key project references produced for this system.

46.1.4. Points of ContactIdentify the System Proponent in this section. Provide the name of the responsible organization(s) and titles of the staff that conducted the system review.

46.1.5. GlossaryProvide a glossary of all terms and abbreviations used in the report that may be unfamiliar to the reader. If it is several pages in length, it may be placed as an appendix.

46.2. REVIEW PROCESSThis section provides an overview of the review process and its approach. This information may differ, depending on if the system review focused on performance, user satisfaction, or both.

46.2.1. System OverviewIn this section, provide a brief general overview of the system reviewed. Examples of information that would be relevant to this section include the following:

System name



QPM #

AQS 200-001-WI

Revision

1


Date of initial implementation Date of latest modification Type of system (such as, administrative, financial) Type of processing (batch, online, transaction processing) Functional requirements traceability matrix System diagram and narrative description Number of computer programs within the system Programming language(s) and database management systems (DBMSs) used Processing frequency Total monthly processing hours System origination (commercial off-the-shelf or AVS-developed) Testing methodology (test data, live data) for initial system tests Testing methodology (test data, live data) for latest modification Availability of test results Date of last system review, if any List of users List of issues identified in last system review

Expand or contract this list as necessary to include all important aspects of the system that are relevant to the system review. It is not necessary to provide information on all the items in the list above if they are not relevant to the review.

46.2.2. Functional System Description and Data UsageThis section briefly describes what the system does functionally and how the data are used by the system.

46.2.3. Performance ReviewThis section should address the review, system response, capacity, correctness, and other pertinent performance factors.

46.2.3.1. System Response

To evaluate the responsiveness of the system, it may be appropriate to use a system monitor on mainframe-based systems. For example, for a transaction processing system, data on the number of times each of the system's programs have been executed during a workday, week, or month should be collected as appropriate. The monitor may also provide data on the average and worst-case delay experienced by the programs and the average and worst-case queue lengths. To evaluate the responsiveness of the system for LAN-based systems, it may be appropriate to place a monitor or protocol analyzer on the LAN.

46.2.3.2. System Capacity

This section examines the ability of the system being reviewed to determine if any performance limitations result from operating the system near the limits of its capacity. For example, for



QPM #

AQS 200-001-WI

Revision

1


mainframe computer applications using a DBMS, lack of main memory or selection of inappropriate buffer sizing during system generation could result in excessive disk reads and writes that would slow the applications' response. Similarly, a lack of adequate excess hard disk storage could result in large queues at disk controllers, substantially slowing the actual, observed average disk access time. On LAN-based systems, hosting all applications on a server with only one large disk drive and controller could lead to bottlenecks in performance for LAN-based applications. In addition, there may be simple system capacity considerations, such as in an application hosted on a system that has only enough hard disk space available for a limited number of data records.

46.2.3.3. System Correctness

Depending on the purpose of the review, it may be appropriate to examine the correctness of the system calculations, output, and reports. Presumably, this was done during unit testing and system testing. The intent of examining correctness during the Periodic System Review is to determine if the system is operating correctly with actual operational data inputs because the operational data may differ somewhat from the test data. Examples of items to be evaluated include the following:

Values used for case codes Correctness of field definitions Values within data fields Combinations of data fields Calculations Missing data Extraneous data Amounts Units Logic paths and decisions Limits or reasonableness checks Signs Cross-footing of quantitative data Control totals

If the system maintains an audit trail log of hardware and software failures, examine this log to determine the failure modes of the system.

46.2.3.4. Other

This section discusses the approach to any performance issues that are not easily categorized under the topics listed in the previous sections.

46.2.4. User Satisfaction ReviewA User Satisfaction Review records the effectiveness, correctness, and ease of use of the system from the users' perspective. If appropriate, this review can be used at any point during the information systems life cycle. Summarize the results of the review.



QPM #

AQS 200-001-WI

Revision

1


46.3. FINDINGSThis section describes the major findings, results, or conclusions of the review. The intent is to provide management with information for decision making about the system under review.

Rank or prioritize the findings by importance, if applicable. Otherwise, group them logically, as appropriate. The ranking, prioritizing, or grouping facilitates making a logical linkage to Section on Recommendations, which provides recommendations regarding the findings.

Provide as much detail as necessary to describe the findings clearly and to support the recommendations. The following list provides some examples of information that might be included in this section:

What and where short-term problem areas exist (such as, missing tapes, misrouted material)

What and where long-term problem areas exist (such as, machine capacity problems)

References to meetings, interviews, and surveys conducted, with a description of their results or outcomes

References to supporting statistics or reports

46.4. RECOMMENDATIONSThis section presents the recommendations derived from the findings of the system review. These recommendations should be phrased as proposals for management consideration and approval.

Depending on the purpose and scope of the specific system review as defined by AVS management, it may be appropriate to provide multiple alternative recommendations for the findings. If alternative recommendations are provided, then describe the advantages, disadvantages, costs, tradeoffs, etc. associated with each alternative. Rank, prioritize, or group the recommendations logically, as appropriate. Relate the ranking, prioritization, or grouping of the recommendations to that of the findings in Section - Findings.

46.5. APPROVALS AND APPENDICESReference any management approvals and include any appendices needed to support the Periodic System Review Report in this section.

46.5.1. ApprovalReference or describe the final approval of the Periodic System Review Report, which may come from different levels of authority within the organization, depending on the size and importance of the items being reviewed. Thus, complete this section after the initial Periodic System Review Report has been presented to management. After management approval of the report, update this section. Also update this section to provide an annotation of the recommendations or course of action selected by management, if appropriate.



QPM #

AQS 200-001-WI

Revision

1


46.5.2. AppendicesIn this section, reference any additional items necessary to support the system review from other documents, or add to the appendices, as appropriate.

46.6. PERIODIC SYSTEM REVIEW REPORT OUTLINECover Page

Table of Contents

1.0 Introduction

1.1 Purpose

1.2 Scope



1.5 Glossary

2.0 Review Process

2.1 System Overview

2.2 Functional System Description and Data Usage

2.3 Performance Review

2.3.1 System Response

2.3.2 System Capacity

2.3.3 System Correctness

2.3.4 Other

2.4 User Satisfaction Review

3.0 Findings

4.0 Recommendations

5.0 Approvals and Appendices

5.1 Approvals

5.2 Appendices



QPM #

AQS 200-001-WI

Revision

1


47 USER SATISFACTION REVIEW

47.1. INTRODUCTIONThe User Satisfaction Review Survey is used to gather the data needed to analyze current user satisfaction with the performance capabilities of an existing application. The survey is administered annually, or as needed. The User Satisfaction Review outline (attached), illustrates this form.

47.2. ROLES AND RESPONSIBILITIESThe following are the roles and responsibilities of team members in administering the User Satisfaction Review:

The Project Manager has primary responsibility for planning, scheduling, and conducting the user satisfaction review.

The Quality Assurance organization provides major assistance in planning the review and in evaluating the results.

The IRM Manager and the System Proponent are responsible for reviewing the results of the survey.

Users are responsible for completing and returning the survey forms accurately and timely.

47.3. PROCESSComply with the following process to distribute and complete the forms:

The Project Manager or designated assistant completes the following items:

Name of system: The standard full name of the application, including version and release numbers

Data processing identification number: The Configuration Management, Configuration Item Identification number for the application

Type of system: The business purpose or function served by the application, and whether mainframe or client/server

Part of system to be evaluated: The standard full name of the component or subsystem being evaluated

Name: The full name of the user who is responsible for completing the evaluation

Date: The date the form is due back to IRM

Title: The title of the user who is responsible for completing the evaluation

Organization: The name of the organization of the user who is responsible for completing the evaluation

Phone number/address: The phone number and address of the user who is responsible for completing the evaluation



QPM #

AQS 200-001-WI

Revision

1


The user identified in the Name field completes the following items:

Extent of your knowledge about the system: The percentage of the entire system you have a) studied documentation for; b) used; and c) written supplemental documentation about (including detailed problem reports)

The purposes for which you use the system: Check "Yes" to all that apply, and "No" to those that do not; list the "Other" uses in the space available

The importance of the system in your office environment: A number from 1 to 10, where 1 means not important at all, and 10 means very important

The ease of understanding of the system: A number from 1 to 10, where 1 means the system is difficult to use (labels, toolbar icons, help text instructions are confusing, misleading, unclear, and not intuitive, and/or you are frequently required to repeat your work) and 10 means the system is very easy to understand (labels, toolbar icons, help text instructions are clear, and the use of the system is nearly intuitive)

Can the system be used as is?: YES or NO field; checking a NO means that there needs to be some correction, and/or further identification and/or analysis of problems, before you are willing to resume use of the system

In your judgment, is the system…: YES or NO field for each attribute listed; and further details and examples for the NO answers

In your opinion, should the system…: YES or NO field for each attribute listed; and further details and examples for the YES answers

If you maintain manual records…: Brief explanation, in the space available, of why it is necessary to maintain manual records to supplement the computer-processed information

Does the system duplicate other information…: YES or NO field; a brief explanation of a YES answer, indicating what information is duplicated and where it resides

Can you readily obtain the information from other sources…: YES or NO field; if YES, a list of the information items and the sources

Do you supply the input data…: YES or NO field

When you receive output, do you check it for quality…: YES or NO field; if NO, an identification of the person or group that performs the quality check

Is the system ever rerun…: YES or NO field; if YES, a description of the monthly frequency, the reason for the rerun, and the procedure used to validate the correctness of the rerun output

If you have had/were to have problems with the system…: A description of with whom you did, or would discuss these problems.

Did anyone in your organization help design the system…: YES or NO field

Could you effectively perform your duties…: YES or NO field



QPM #

AQS 200-001-WI

Revision

1


Does the system save any clerical effort…: YES or NO field; and an explanation of your answer either way

Can the system and its outputs be improved…: YES or NO field; and an explanation of your answer either way

How often do you use the system…: YES or NO field for each choice; and an explanation of your answer if you select YES for Other; for each YES answer needing more explanation, add an explanation in the space provided.

47.4. USER SATISFACTION REVIEW OUTLINEThis review is designed to obtain user feedback on information systems. Feedback gathered in this review can help to determine whether information systems are accurate and reliable.

System Identification

1. Name of system

2. Data processing identification number, if any

3. Type of system

4. Part of system to be evaluated

User Identification

6. Name

7. Date

8. Title

9. Organization

10. Phone number/address

11. What is the extent of your knowledge about the system?

For what purpose do you use the system? YES NO

- Initiate transactions __ __- Authorize changes to the system __ __- Operate computer terminal __ __- Maintain data controls __ __- Design/program applications __ __- Other (explain)

13. In relation to the work of your office environment, estimate the importance of the system on a scale from 1 (not important) to 10 (very important).

14. State the ease of understanding the system on a scale from 1 (difficult) to 10 (very easy to understand).



QPM #

AQS 200-001-WI

Revision

1


15. Can the system be used as is, without correction, further identification, or analysis? YES NO

16. In your judgment, is the system: YES NO

- Accurate and reliable? __ __

- Available when needed? __ __

- Current and up-to-date? __ __

- Useful? __ __

For each "No" answer, please explain below, and provide examples.

17. In your opinion, should the system: YES NO

- Provide more data? __ __

- Provide less data? __ __

- Be combined with other output products? __ __

- Be considered obsolete? __ __

- Be improved to make your job easier? __ __

For each "yes" answer, please explain below.

18. If you maintain manual records to supplement computer-processed information, briefly explain why.

19. Does the system duplicate any other information you receive? __YES __NO If "yes," briefly explain.

20. Can you readily obtain, from other sources, the information in the system? __YES __NO If "yes," list the sources.

21. Do you supply the input data for this system? __YES __NO

22. When you receive output, do you check it for quality? __YES __NO If "no," please identify the person or group performing this function.

23. Is the system ever rerun? __YES __NO If "yes":

- How frequently?

- Why were the reruns necessary?

- How do you make sure that the rerun material is correct?

24. If you have had/were to have problems with this system, with whom did/would you discuss them?

If yes, attach copies of recent correspondence.

26. Did anyone in your organization help design the system? __YES __NO

27. Could you effectively perform your duties: YES NO

- Without this system? __ __



QPM #

AQS 200-001-WI

Revision

1


- If the system output were produced less often? __ __

28. Does the system save any clerical effort? __ __ Explain.

29. Can this system and its outputs be improved to make your job easier? __YES __NO Explain.

30. How often do you use this system? YES NO

- Daily? __ __

- Weekly? __ __

- Monthly? __ __

- Annually? __ __

- Never? __ __

- Other? (Explain)

For each "yes" answer, please explain below.



QPM #

AQS 200-001-WI

Revision

1


48 DISPOSITION PLAN

The Disposition Plan is the most significant deliverable in the disposition of the information system, and the plan will vary according to system and Service requirements. The objectives of the plan are to end the operation or the system in a planned, orderly manner and to ensure that system components and data are properly archived or incorporated into other systems. At the end of this task, the system will no longer exist as an independent entity. The completion of the systems life cycle is carefully planned and documented to avoid disruption of the organizations using the system or the operation of other systems that will use the data and/or software of the present system.

The Disposition Plan needs to be an extension of the Records Management function. Records Management-- what is kept, what is a legal "record," retention period, etc.-- is a topic beyond the scope of this SDLC. The software, hardware, and data of the current system are disposed of in accordance with organization needs and pertinent laws and regulations. Software or data of the system may be transferred to other existing systems, migrated to an entirely new system, or archived for future use. Hardware is made available for future use, added to surplus, or discarded.

In conducting the disposition task, the following items should be considered:

1. All known users should be informed of the decision to terminate operation of the system before the actual termination date.

2. Although the current system may be terminated, in many cases the data will continue to be used through other systems. The specific processing logic used to transfer the data to another system is developed as part of the data conversion planning for that system.

3. In some instances, software may be transferred to a replacement system. For example, a component of the current system may become a component of the replacement system without significant rewriting of programs.

4. Effective reactivation of the system in the future will depend heavily on having complete documentation. It is generally advisable to archive all documentation, including the life-cycle products generated during the earliest tasks of the life cycle as well as the documentation for users and for operation and maintenance personnel.

5. The Disposition Plan addresses how the various components of the system are handled at the completion of operations, including software, data, hardware, communications, and documentation. The plan also notes any future access to the system. The plan is led/performed by the Project Manager; supported by the records management staff, the project team, and the functional staff; and reviewed by the QA manager. Other tasks include the following:

6. Notify all known users of the system of the planned date after which the system will no longer be available. Work with the FOIA/PA representative process any Federal Register regarding system of records notification.



QPM #

AQS 200-001-WI

Revision

1


7. Copy data to be archived onto permanent storage media, and store media in a location designated by the Disposition Plan. Work with the project management team for other systems to effect a smooth transfer of data from the current system to these systems.

8. Copy software onto permanent storage media, and store media in location designated in

9. Disposition Plan. (Software to be stored may include communications and systems software as well as application software.) Work with the project team for other systems to ensure effective migration of the current system software to be used by these systems.

10. Store other life-cycle products, including system documentation, in archive locations designated by the Disposition Plan.

11. Dispose of equipment used exclusively by this system in accordance with the Disposition Plan (refer to excess procedures).

12. Complete and update the Disposition Plan to reflect actual disposition of data, software, and hardware.

13. Plan for the shutdown of the project, including the reassignment of project staff, the storage of project records, and the release of project facilities


48.1.1. Purpose and ScopeThis section describes the purpose and scope of the Disposition Plan. Reference the information system name and provide identifying information about the system undergoing disposition.

48.1.2. Points of ContactThis section identifies the System Proponent. Provide the name of the responsible organization and staff (and alternates, if appropriate) who serve as points of contact for the system disposition. Include telephone numbers of key staff and organizations.

48.1.3. Project ReferencesThis section provides a bibliography of key project references and deliverables that have been produced before this point in the project development. These documents may have been produced in a previous development life cycle that resulted in the initial version of the system now undergoing disposition or may have been produced in subsequent enhancement efforts as appropriate.




QPM #

AQS 200-001-WI

Revision

1


48.2. SYSTEM DISPOSITION48.2.1. NotificationsThis section describes the plan for notifying known users of the system being shut down, and other affected parties, such as those responsible for other, interfacing systems, and operations staff members involved in running the system.

48.2.2. Data DispositionThis section describes the plan for archiving, deleting, or transferring to other systems the data files and related documentation in the system being shut down.

48.2.3. Software DispositionThis section describes the plan for archiving, deleting, or transferring to other systems the software library files and related documentation in the system being shut down.

48.2.4. System Documentation DispositionThis section describes the plan for archiving, deleting, or transferring to other systems the hardcopy and softcopy systems and user documentation for the system being shut down.

48.2.5. Equipment DispositionThis section describes the plan for archiving, deleting, or transferring to other systems the hardware and other equipment used by the system being shut down.

48.3. PROJECT CLOSEDOWN48.3.1. Project StaffThis section describes the plan for notifying project team members of the shutdown of the system, and the transfer of these team members to other projects.

48.3.2. Project RecordsThis section describes the plan for archiving, deleting, or transferring to other projects the records of project activity for the project that has been maintaining the system being shut down.

48.3.3. FacilitiesThis section describes the plan for transferring or disposing of facilities used by the project staff for the system being shut down.

48.4. DISPOSITION PLAN OUTLINECover Page

Table of Contents

1.0 Introduction1.1 Purpose and Scope




QPM #

AQS 200-001-WI

Revision

1



1.4 Glossary

2.0 System Disposition2.1 Notifications

2.2 Data Disposition

2.3 Software Disposition

2.4 System documentation Disposition

2.5 Equipment Disposition

3.0 Project Closedown3.1 Project Staff

3.2 Project Records

3.3 Facilities



QPM #

AQS 200-001-WI

Revision

1


49 POST-TERMINATION REVIEW REPORT

The Post-Termination Review shall be performed after the end of the Disposition Phase. This phase-end review shall be conducted within 6 months after disposition of the system. The Post-Termination Review Report documents the lessons learned from the shutdown and archiving of the terminated system.

The Post-termination Review Report details the findings of the Disposition Phase review. It can be used to document and ensure that all functions have been performed to dispose of the system. This report can provide a check-list of activities completed to dispose of the system. It should include the details where to find all products and documentation that has been archived.


49.1.1. Purpose and ScopeThis section describes the purpose and scope of the Disposition Plan. Reference the information system name and provide identifying information about the system undergoing disposition.

49.1.2. Points of ContactThis section identifies the System Proponent. Provide the name of the responsible organization and staff (and alternates, if appropriate) who serve as points of contact for the system disposition. Include telephone numbers of key staff and organizations.

49.1.3. Project ReferencesThis section provides a bibliography of key project references and deliverables that have been produced before this point in the project development. These documents may have been produced in a previous development life cycle that resulted in the initial version of the system now undergoing disposition or may have been produced in subsequent enhancement efforts as appropriate.


49.2. LESSONS LEARNED

49.2.1. Data DispositionThis section describes what happened to the data from the old system. Explain any problems or mishaps that might have occurred during this phase.

49.2.2. Software DispositionThis section describes what happened to the software from the old system. Explain any lessons learned from performing this task during the Disposition Phase.



QPM #

AQS 200-001-WI

Revision

1


49.2.3. Equipment DispositionThis section describes what happened to the equipment from the old system. Explain where it is located, or if it was excessed, the date it was excessed.

49.3. ARCHIVINGThis section explains what happened to the old system. It could be a check off sheet or in report format.

49.3.1. DataThis section explains where the old data is stored. If the old data was incorporated into a new system, so state here.

49.3.2. SoftwareThis section explains where the old software is located.

49.3.3. HardwareThis section explains where the old hardware is located. If the equipment has been excessed, provide the date it was excessed.

49.4. POST-TERMINATION REVIEW REPORT OUTLINECover Page

Executive Summary

Table of Contents

1.0 Introduction




1.4 Glossary

2.0 Lessons Learned

2.1 Data Disposition

2.2 Software Disposition

2.3 Equipment Disposition

3.0 Archiving

3.1 Data

3.2 Software

3.3 Hardware



QPM #

AQS 200-001-WI

Revision

1


50 INFORMATION SECURITY REQUIREMENTS

As threats to information technology have become more prevalent, the federal Government has provided many different sources of information for system owners about how to secure their systems. Because these sources often overlap or conflict, this document has been prepared specifically for AVS system owners.

This document is one of two that AVS system owners should use to provide and maintain security in their systems. The second is published by the National Institute of Standards and Technology (NIST): NIST Special Publication 800-53, “Recommended Security Controls for Federal Information Systems”, available at NIST’s web site, http://csrc.nist.gov/publications/nistpubs/index.html

For more information concerning this document, please contact Melanie Boteler, AVS Information Systems Security Manager (ISSM) at 202-493-4133.

AVS Security Requirements for Information Systems

Risk Assessment 800-53 Control Family (RA)

Risk will be periodically assessed. NIST SP800-26

Program officials will understand the risk to systems under their control. NIST SP800-26

Program officials will determine the acceptable level of risk. NIST SP800-26

The security controls of the system will be reviewed. NIST SP800-26

The security controls of the interconnected systems will be reviewed. NIST SP800-26

Management will ensure that corrective actions are effectively implemented. NIST SP800-26

Planning 800-53 Control Family (PL)

A system security plan will be documented for the system. NIST SP800-26

A system security plan will be documented for all NIST SP800-26UNCONTROLLED COPY WHEN DOWNLOADED


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


QPM #

AQS 200-001-WI

Revision

1



interconnected systems if the boundary controls are ineffective.

The system security plan will be kept current. NIST SP800-26

System and Services Acquisition 800-53 Control Family (SA)

A system development life cycle methodology will be developed. NIST SP800-26

Changes will be controlled as programs progress through testing to final approval. NIST SP800-26

Certification, Accreditation, and Security Assessments 800-53 Control Family (CA)

The system will be certified/recertified and authorized to process (accredited). NIST SP800-26

Interim authority to process will be in compliance with specified agency procedures. NIST SP800-26

Personnel Security 800-53 Control Family (PS)

Duties will be separated to ensure least privilege. NIST SP800-26

Duties will be separated to ensure least individual accountability. NIST SP800-26

Background screening for assigned positions will be completed prior to granting access. NIST SP800-26

Physical and Environmental Protection 800-53 Control Family (PE)

Physical security controls that are commensurate with the risks of physical damage or access will be implemented.

NIST SP800-26

Data will be protected from interception. NIST SP800-26



QPM #

AQS 200-001-WI

Revision

1



Mobile systems will be protected. NIST SP800-26

Portable systems will be protected. NIST SP800-26

Contingency Planning 800-53 Control Family (CP)

The most critical and sensitive operations and their supporting computer resources will be identified. NIST SP800-26

A comprehensive contingency plan will be developed and documented. NIST SP800-26

Contingency/disaster recovery plans will be tested in place. NIST SP800-26

Configuration Management 800-53 Control Family (CM)

Access to system software and hardware will be limited. NIST SP800-26

All new and revised hardware and software will be authorized, tested and approved before implementation.

NIST SP800-26

Systems will be managed to reduce vulnerabilities. NIST SP800-26

Maintenance 800-53 Control Family (MA)

Virus detection and elimination software will be installed and activated. NIST SP800-26

Sufficient documentation that explains how software/hardware is to be used will be provided. NIST SP800-26

Formal security and operational procedures will be documented. NIST SP800-26

System and Information Integrity 800-53 Control Family (SI)

Data integrity and validation controls will be used to NIST SP800-26 UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1



provide assurance that the information has not been altered.

Data integrity and validation controls will be used to provide assurance that the system functions as intended.

NIST SP800-26

Media Protection 800-53 Control Family (MP)

User support will be provided. NIST SP800-26

Media controls will be provided. NIST SP800-26

Incident Response 800-53 Control Family (IR)

A capability to provide help to users when a security incident occurs in the system will be provided. NIST SP800-26

Incident related information will be shared with appropriate organizations. NIST SP800-26

Awareness and Training 800-53 Control Family (AT)

Employees will be provided adequate training to fulfill their security responsibilities. NIST SP800-26

Identification and Authentication 800-53 Control Family (IA)

Users will be individually authenticated via passwords, tokens, or other devices. NIST SP800-26

Access Control 800-53 Control Family (AC)

Access controls will enforce segregation of duties. NIST SP800-26

Logical access controls will restrict users to authorized NIST SP800-26



QPM #

AQS 200-001-WI

Revision

1



transactions and functions.

Audit and Accountability 800-53 Control Family (AU)

Activity involving access to and modification of sensitive or critical files will be logged, monitored. NIST SP800-26

Possible security violations will be investigated. NIST SP800-26

System and Communications Protection 800-53 Control Family (SC)

Logical controls over network access will be provided. NIST SP800-26

Public access the system will be controlled to protect the integrity of the application. NIST SP800-26

Public access the system will be controlled to protect the confidence of the public. NIST SP800-26



QPM #

AQS 200-001-WI

Revision

1


51 GLOSSARY

-A-Acceptance Test - Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. See User Acceptance Test.

Accreditation - Formal declaration by an accrediting authority that a computer system is approved to operate in a particular security mode using a prescribed set of safeguards.

Acquisition Plan - A formal document showing how all hardware, software, and telecommunications capabilities, along with resources, are to be obtained during the life of the project.

Activity - A unit of work to be completed in order to achieve the objectives of a work breakdown structure. See Work Breakdown Structure. In process modeling, an activity requires inputs and produces outputs. See Input/Output.

Adaptability - The ease with which software satisfies differing system constraints and user needs.

Adaptive Maintenance - Maintenance performed to change a system in order to keep it usable in a changed environment.

Alias - A name of a data entity or data attribute that is different from its official name.

Allocated Baseline - The approved documentation that describes the design of the functional and interface characteristics that are allocated from a higher-level configuration item. See Baseline.

Alternative Work Patterns - Work pattern that permits tailoring a project plan to meet the specific needs of the project and still conform to SDLC standards.

Application - A system providing a set of services to solve some specific user problem.

Application Model - A model used to graphically and textually represent the required data and processes within the scope of the application development project.

Application Software - Software specifically developed to perform a specific type of work; for example, a word processor. Compare to System Software.

Architecture - The structure of a computer system, either a part or the entire system; can be hardware, software, or both.

Audit - A formal review of a project (or project activity) for the purpose of assessing compliance with contractual obligations.

Availability - The degree to which a system (or system component) is operational and accessible when required for use.

-B-



QPM #

AQS 200-001-WI

Revision

1


Backup - v. To copy software files onto a different media that can be sorted separately from the original files and used to restore the original files, if needed. The act of creating these files. n. The set of copied files.

Baseline - A work product (such as software or documentation) that has been formally reviewed, approved, and delivered and can only be changed through formal change control procedures. See Allocated Baseline, Functional Baseline, Operational Baseline, Product Baseline.

Benchmark - A standard against which measurements or comparisons can be made.

Bottom-up - The process of designing a system by designing the low-level components first; then integrating them into large subsystems until the complete system is designed; bottom-up testing tests these low-level components first, using software drivers to simulate the higher level components. See Top-down.

Build - An operational version of a software product incorporating a specified subset of the complete system functionality. See Version.

Business Process Reengineering - The redesign of an organization, culture, and business processes to achieve significant improvements in costs, time, service, and quality.

-C-Capability - A measure of the expected use of a system.

Capacity - A measure of the amount of input a system could process and/or amount of work a system can perform; for example, number of users, number of reports to be generated.

Certification - Comprehensive analysis of the technical and non-technical security features and other safeguards of a system to establish the extent to which a particular system meets a set of specified security requirements.

Change - In Configuration Management, a formally recognized revision to a specified and documented requirement. See Change Control, Change Directive, Change Impact Assessment, Change Implementation Notice.

Change Control - In Configuration Management, the process by which a change is proposed, evaluated, approved (or disapproved), scheduled, and tracked. See Change, Change Directive, Change Impact Assessment, Change Implementation Notice.

Change Control Documents - Formal documents used in the configuration management process to track, control, and manage the change of configuration items over the systems development or maintenance life cycle. See System Change Request, Change Impact Assessment, Change Directive, and Change Implementation Notice.

Change Directive - The formal Change Control Document used to implement an approved change. See Change Control Documents.

Change Impact Assessment - The formal Change Control Document used to determine the effect of a proposed change before a decision is made to implement it. See Change Control Documents.



QPM #

AQS 200-001-WI

Revision

1


Change Implementation Notice - The formal Change Control Document used to report the actual implementation of a change in a system. See Change Control Documents.

Client/Server - A network application in which the end-user interaction with the system (server) is through a workstation (client) that executes some portion of the application.

Code - v. To transform the system logic and data from design specifications into a programming language. n. The computer program itself; pseudo-code is code written in an English-like logical representation, source code is code written in a programming language, object code is code written in machine language.

Compatibility - A measure of the ability of two or more systems (or system components) to exchange information and use the information that has been exchanged. Same as Interoperability.

Component - General term for a part of a software system (hardware or software). See Product.

Computer-aided Software Engineering - An electronic tool that is used to assist in the design, development, and coding of software. See Tools.

Concept of Operations - A formal document that describes the user's environment and process relative to a new or modified system; defines the users, if not already known. Called a CONOPS.

Configuration - The functional and/or physical collection of hardware and software components as set forth in formal documentation. Also, the requirements, design, and implementation that define a particular version of a system (or system component). See Configuration Control, Configuration Item, Configuration Management, Configuration Management Plan, Configuration Status Accounting.

Configuration Audit - Formal review of a project for the purpose of assessing compliance with the Configuration Management Plan.

Configuration Control - The process of evaluating, approving or (disapproving), and coordinating changes to hardware/software configuration items.

Configuration Control Board - The formal entity charged with the responsibility of evaluating, approving (or disapproving), and coordinating changes to hardware/software configuration items.

Configuration Item - An aggregation of hardware and/or software that satisfy an end-use function and is designated by the customer for configuration management; treated as a single entity in the configuration management process. A component of a system requiring control over its development throughout the life-cycle of the system.

Configuration Management - The discipline of identifying the configuration of a hardware/software system at each life cycle phase for the purpose of controlling changes to the configuration and maintaining the integrity and traceability of the configuration through the entire life cycle.



QPM #

AQS 200-001-WI

Revision

1


Configuration Management Plan - A formal document that establishes formal configuration management practices in a systems development/maintenance project. See Configuration Management.

Configuration Status Accounting - The recording and reporting of the information that is needed to effectively manage a configuration; including a listing of the approved configuration identification, status of proposed changes to the configuration, and the implementation status of approved changes. See Configuration.

Contingency Plan - A formal document that establishes continuity of operations processes in case of a disaster. Includes names of responsible parties to be contacted, data to be restored, and location of such data.

Conversion - The process of converting (or exchanging) data from an existing system to another hardware or software environment.

Conversion Plan - A formal document that describes the strategies involved in converting data from an existing system to another hardware or software environment.

Corrective Maintenance - Maintenance performed to correct faults in hardware or software.

Correctness - The degree to which a system or component is free from faults in its specification, design, and implementation.

Cost Analysis - Presents the costs for design, development, installation, operation and maintenance, and consumables for the system to be developed.

Cost-Benefit Analysis - The comparison of alternative courses of action, or alternative technical solutions, for the purpose of determining which alternative would realize the greatest cost benefit; cost-benefit analysis is also used to determine if the system development or maintenance costs still yield a benefit or if the effort should stop.

Cost Estimate - the process of determining the total cost associated with a software development or maintenance project, to include the effort, time, and labor required.

Criteria - A standard on which a decision or judgment may be based; for example, acceptance criteria to determine whether or not to accept a system.

Critical Path - Used in project planning; the sequence of activities (or tasks) that must be completed on time to keep the entire project on schedule; therefore, the time to complete a project is the sum of the time to complete the activities on the critical path.

Critical Review Board - A formal board that guides and monitors the development of requirements that affect current and future AVS systems.

Customer - An individual or organization that specifies the requirements for and formally accepts delivery of a new or modified system; one who pays for the system. The customer may or may not be the user; see User.

-D-Data Dictionary - A repository of information about data, such as its meaning, relationships to other data, origin, usage and format. A data dictionary manages data categories such as aliases, data elements, data records, data structure, data store, data models, data flows, data



QPM #

AQS 200-001-WI

Revision

1


relationships, processes, functions, dynamics, size, frequency, resource consumption and other user-defined attributes.

Database Administrator - The person responsible for managing data at a logical level, namely data definitions, data policies and data security.

Database - A collection of logically related data stored together in one or more computerized files; an electronic repository of information accessible via a query language interface.

Database Management System - A software system that controls storing, combining, updating, retrieving, and displaying data records.

Data Store - A repository of data; a file.

Demonstration - A procedure to verify system requirements that cannot be tested otherwise.

Deliverable - A formal product that must be delivered to (and approved by) the customer; called out in the Task Order.

Delivered System Documentation - Includes the Software Development Document, User Manual, Maintenance Manual, and Operations Manual.

Design Phase - The period of time in the systems development life cycle during which the designs for architecture, software components, interfaces, and data are created, documented, and verified to satisfy system requirements.

Development Phase - The period of time in the systems development life cycle to convert the deliverables of the Design Phase into a complete system.

Disposition Phase - The time when a system has been declared surplus and/or obsolete and the task performed is either eliminated or transferred to other systems.

Disposition Plan - A formal plan providing the full set of procedures necessary to end the operation or the system in a planned, orderly manner and to ensure that system components and data are properly archived or incorporated into other systems.

Document - Written and/or graphical information describing, defining, specifying, reporting, or certifying activities, requirements, procedures, reviews, or results. See Product.

-E-Effectiveness - The degree to which a system's features and capabilities meet the user's needs.

Efficiency - The degree to which a system or component performs its designated functions with minimum consumption of resources.

Element - A subsystem, component, or unit; either software or hardware, as defined by the project.

Enhancement - Maintenance performed to provide additional functional or performance requirements.

Entity - Represents persons, places, events, things, or abstractions that are relevant to AVS and about which data are collected and maintained.



QPM #

AQS 200-001-WI

Revision

1


-F-Fault Tolerance - The ability of a system (or system component) to continue normal operation despite the presence of hardware or software faults.

Feasibility - The extent to which the benefits of a new or enhanced system will exceed the total costs and also satisfies the business requirements.

Feasibility Study - A formal study to determine the feasibility of a proposed system (new or enhanced) in order to make a recommendation to proceed or to propose alternative solutions.

Field Test - Testing that is performed at the user site.

Fielded System - An operational system that is installed at the user site.

Full Sequential - The systems development work pattern defined by the nine life cycle phases described in the SDLC Guidance Document.

Functionality - The relative usefulness of a functional requirement as it satisfies a business need.

Functional Baseline - The approved documentation that describes the functional characteristics of the system, subsystem, or component. See Baseline.

Functional Configuration Audit - An audit to ensure that the functional requirements have been met by the delivered configuration item. See Audit.

Functional Requirement - A requirement that specifies a function (activity or behavior, based on a business requirement) that the system (or system component) must be capable of performing.

Functional Requirements Document - A formal document of the business (functional) requirements of a system; the baseline for system validation.

Functional Test - Testing that ignores the internal mechanism of a system (or system component) and focuses solely on the outputs generated in response to selected inputs and execution conditions. Same as black-box testing.

-G-Gantt Chart - A list of activities plotted against time, showing start time, duration, and end time; also known as a bar chart.

-H-Hardware - The physical portion of a system (or subsystem), including the electrical components. Compare to Software.

Host - The computer that controls communications in a network that administers a database; the computer on which a program or file is installed; a computer used to develop software intended for another computer. See Target.

-I-Implementation - Installing and testing the final system, usually at the user (field) site; the process of installing the system.



QPM #

AQS 200-001-WI

Revision

1


Implementation Phase - The period of time in the systems development life cycle when the system is installed, made operational, and turned over to the user (for the beginning of the Operations and Maintenance Phase).

Implementation Plan - A formal document that describes how the system will be installed and made operational.

Information System Security Manager (ISSM) - The federal official who is responsible for implementing and managing the Information Security program within each line of business. Within AVS, the ISSM oversees the results of all security activity, including security activities for planning; awareness training; risk management; configuration management; certification and accreditation; compliance assurance; incident reporting; and guidance and procedures.

Information Security – The set of practices which ensure that the confidentiality, availability, and integrity of systems and data are protected.

Information Technology - The application of engineering solutions in order to develop computer systems that process data.

Input/Output - The process of entering information into a system (input) and its subsequent results (output). A hardware device that enables input (for example, a keyboard or card reader) and output (for example, a monitor or printer). Collectively known as I/O.

Inspection - A semiformal to formal technique in which software requirements, design, or code are examined in detail by a person or group other than the originator to detect errors. See Peer Review, Walk-through.

Integrated Product Team - A multidisciplinary group of people who support the Project Manager in the planning, execution, delivery and implementation of life cycle decisions for the project.

Integration Document - A formal document that describes how the software components, hardware components, or both are combined and the interaction between them.

Integration and Test Phase - Life cycle phase during which subsystem integration, system, security, and user acceptance testing are conducted; done prior to the Implementation Phase.

Integration Test - Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them.

Integrity - The degree to which a system (or system component) prevents unauthorized access to, or modification of, computer programs or data.

Iterative - A procedure in which repetition of a sequence of activities yields results successively close to the desired state; for example, an iterative life cycle in which two or more phases are repeated until the desired product is developed.

Interface - To interact or communicate with another system (or system component). An interface can be software and/or hardware. See User Interface.

Interface Control Document - Specifies the interface between a system and an external system(s).



QPM #

AQS 200-001-WI

Revision

1


Interoperability - A measure of the ability of two or more systems (or system components) to exchange information and use the information that has been exchanged. Same as Compatibility.

Information Technology Systems Security Certification and Accreditation - A formal set of documents showing that the installed security safeguards for a system are adequate and work effectively.

-L-Lessons Learned - A formal or informal set of examples collected from experience (for example, experience in system development) to be used as input for future projects to know what went well and what did not; collected to assist other projects.

Library - A configuration controlled repository for system components (for example, documents and software).

Life Cycle - All the steps or phases a project passes through during its system life; from concept development to disposition. There are nine life cycle phases in the SDLC.

-M-Maintainability - The ease with which a software system (or system component) can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment.

Maintenance - In software engineering, the activities required to keep a software system operational after implementation. See Adaptive Maintenance, Corrective Maintenance, Enhancement, Perfective Maintenance.

Maintenance Manual - A formal document that provides systems maintenance personnel with the information necessary to maintain the system effectively.

Maintenance Review - A formal review of both the completed and pending changes to a system with respect to the benefits achieved by completing the recommended changes; also provides information about the amount of maintenance required based on activity to date. Part of the Post-Implementation Review Report.

Measurement - In project management, the process of collecting, analyzing and reporting metrics data.

Methodology - A set of methods, procedures, and standards that define the approach for completing a system development or maintenance project.

Metrics - A quantitative measure of the degree to which a system, component, or process possesses a given attribute.

Migration - Porting a system, subsystem, or system component to a different hardware platform.

Milestone - In project management, a scheduled event that is used to measure progress against a project schedule and budget.

Mission - The goals or objectives of an organization or activity.



QPM #

AQS 200-001-WI

Revision

1


Model - A simplified representation or abstraction (for example, of a process, activity, or system) intended to explain its behavior.

Module - In system design, a software unit that is a logically separate part of the entire program. See Unit.

-N-Non-technical - Relating to agreements, conditions, and/or requirements affecting the management activities of a project. Compare to Technical.

-O-Operational Baseline - Identifies the system accepted by the users in the operational environment after a period of onsite test using production data. See Baseline.

Operations Manual - A formal document that provides a detailed operational description of the system and its interfaces.

Operations and Maintenance (O&M) Phase - The period of time in the systems development life cycle during which a software product is employed in its operational environment, monitored for satisfactory performance, and modified as necessary to correct problems or to respond to changing requirements.

-P-Peer Review - A formal review where a product is examined in detail by a person or group other than the originator. See Inspection, Walk-through.

Perfective Maintenance - Software maintenance performed to improve the performance, maintainability, or other attributes of a computer program.

Performance Measures - A category of quality measures that address how well a system functions.

Performance Measurement and Capacity Planning - A set of procedures to measure and manage the capacity and performance of information systems equipment and software.

Performance Review - Formal review conducted to evaluate the compliance of a system or component with specified performance requirements.

Periodic System Review - Formal review conducted (usually annually) during the Operations and Maintenance Phase to evaluate system performance, user satisfaction with the system, adaptability to changing business needs, and new technologies that might improve the system.

Periodic System Review Report - A formal document detailing the findings of the Periodic System Review. See Periodic System Review.

Phase - A defined stage in the systems development life cycle; there are nine phases in the full, sequential life cycle.

Phase Review - A formal review conducted during a life cycle phase; usually at the end of the phase or at the completion of a significant activity.



QPM #

AQS 200-001-WI

Revision

1


Physical Configuration Audit - An audit to ensure that all physical attributes listed in the design requirements have been met by the configuration item being delivered.

Pilot - An alternative work pattern to develop a system to demonstrate that the concept is feasible in an operational environment. Pilots are used to provide feedback to refine the final version of the product and are fielded for a preset, limited period of time. Compare to a Prototype.

Planning Phase - The period of time in the systems development life cycle in which a comprehensive plan for the recommended approach to the systems development or maintenance project is created. Follows the Systems Concept Development Phase, in which the recommended approach is selected.

Post-Implementation Review - A formal review to evaluate the effectiveness of the systems development effort after the system is operational (usually for at least six months).

Post-Implementation Review Report - A formal document detailing the findings of the Post-Implementation Review. See Post-Implementation Review.

Post-Termination Review - A formal review to evaluate the effectiveness of a system disposition.

Post-Termination Review Report - A formal document detailing the findings of the Post-Termination Review. See Post-Termination Review.

Privacy Act Notice - For any system that has been determined to be an official System of Records (in terms of the criteria established by the Privacy Act), a special notice must be published in the Federal Register that identifies the purpose of the system; describes its routine use and what types of information and data are contained in its records; describes where and how the records are located; and identifies who the System Manager is.

Procedure - A series of steps (or instructions) required to perform an activity. Defines "how" to perform an activity. Compare to Process.

Process - A finite series of activities as defined by its inputs, outputs, controls (for example, policy and standards), and resources needed to complete the activity. Defines "what" needs to be done. Compare to Procedure.

Process Model - A graphical representation of a process.

Process Review - A formal review of the effectiveness of a process.

Product - General term for an item produced as the result of a process; can be a system, subsystem, software component, or a document.

Product Baseline - The set of completed and accepted system components and the corresponding documentation that identifies these products. See Baseline.

Production - A fully documented system, built according to the SDLC, fully tested, with full functionality, accompanied by training and training materials, and with no restrictions on its distribution or duration of use.

Product Review - A formal review of a product software (or document) to determine if it meets its requirements. Can be conducted as a peer review.



QPM #

AQS 200-001-WI

Revision

1


Program Specification - A description of the design logic in a software component, generally using pseudo-code. See Code.

Project - The complete set of activities associated with all life cycle phases needed to complete a systems development or maintenance effort from start to finish (may include hardware, software, and other components); the collective name for this set of activities. Typically a project has its own funding, cost accounting, and delivery schedule.

Project Management - The process of planning, organizing, staffing, directing, and controlling the development and/or maintenance of a system.

Project Management Plan - A formal document detailing the project scope, activities, schedule, resources, and security issues. The Project Management Plan is created during the Planning Phase and updated through the Disposition Phase.

Project Manger - The person with the overall responsibility and authority for the day-to-day activities associated with a project.

Prototype - A system development methodology to evaluate the design, performance, and production potential of a system concept (it is not required to exhibit all the properties of the final system). Prototypes are installed in a laboratory setting and not in the field, nor are they available for operational use. Prototypes are maintained only long enough to establish feasibility. Compare to a Pilot.

-Q-Quality - The degree to which a system, component, product, or process meets specified requirements.

Quality Assurance - A discipline used by project management to objectively monitor, control, and gain visibility into the development or maintenance process.

Quality Assurance Plan - A formal plan to ensure that delivered products satisfy contractual agreements, meet or exceed quality standards, and comply with approved systems development or maintenance processes.

Quality Assurance Review - A formal review to ensure that the appropriate Quality Assurance activities have been successfully completed, held when a system is ready for implementation.

-R-Rapid Application Development - In a RAD work pattern, the Requirements Definition and Design phases are iteratively conducted; in this process, a rough set of requirements is used to create an initial version of the system, giving users visibility into the look, feel, and system capabilities. User evaluation and feedback provide revisions to the requirements, and the process is repeated until the requirements are considered to be complete.

Records Disposition Schedule - Federal regulations require that all records no longer needed for the conduct of the regular business of the agency be disposed of, retired, or preserved in a manner consistent with official Records Disposition Schedules.

Records Management - The formal set of system records (for example, files, data) that must be retained during the Disposition Phase; the plan for collecting and storing these records.



QPM #

AQS 200-001-WI

Revision

1


Recoverability - The ability of a software system to continue operating despite the presence of errors.

Reengineering - Rebuilding a process to suit some new purpose; for example, a new business process.

Regression Test - In software maintenance, the rerunning of test cases that previously executed correctly in order to detect errors introduced by the maintenance activity.

Release - A configuration management activity wherein a specific version of software is made available for use.

Reliability - The ability of a system (or system component) to perform its required functions under stated conditions for a specified period of time.

Requirement - A capability needed by a user; a condition or capability that must be met or possessed by a system (or system component) to satisfy a contract, standard, specification, or other formally imposed documents.

Requirements Analysis Phase - The period of time in the systems development life cycle during which the requirements for a software product are formally defined, documented and analyzed.

Requirements Management - Establishes and controls the scope of system development efforts and facilitates a common understanding of system capabilities between the System Proponent, developers, and future users.

Requirements Traceability Matrix - Provides a method for tracking the functional requirements and their implementation through the development process.

Resource - In management, the time, staff, capital and money available to perform a service or build a product; also, an asset needed by a process step to be performed.

Reverse Engineering - A software engineering approach that derives the design and requirements of a system from its code; often used during the maintenance phase of a system with no formal documentation.

Review - A formal process at which an activity or product (for example, code, document) is presented for comment and approval; reviews are conducted for different purposes, such as peer reviews, user reviews, management reviews (usually for approval) or done at a specific milestone, such as phase reviews (usually to report progress).

Review Report - A formal document that records the results of a review.

Risk - A potential occurrence that would be detrimental to the project; risk is both the likelihood of the occurrence and the consequence of the occurrence.

Risk Assessment - The process of identifying areas of risk; the probability of the risk occurring, and the seriousness of its occurrence; also called risk analysis.

Risk Management - The integration of risk assessment and risk reduction in order to optimize the probability of success (that is, minimize the risk).



QPM #

AQS 200-001-WI

Revision

1


Risk Management Plan - A formal document that identifies project risks and specifies the plans to reduce these risks.

Role - A defined responsibility (usually task) to be carried out by one or more individuals.

Rules of System Use – A document which defines expectations for users to protect AVS information and assets.

-S-Scope - The established boundary (or extent) of what must be accomplished; during planning, this defines what the project will consist of (and just as important, what the project will not consist of).

Security - The establishment and application of safeguards to protect data, software, and hardware from accidental or malicious modification, destruction, or disclosure.

Security Certification and Accreditation Package (SCAP) - A formal set of documents which includes the results of information security assessment and implementation for each system. The contents of the SCAP are described in the FAA SCAP Handbook published by the Office of Information Security (AIS).

Security Controls – Those management, operational, or technical features of the system which are implemented to protect the system from potential harm.

Security Risk Assessment - Tool that permits developers to make informed decisions relating to the acceptance of identified risk exposure levels or implementation of cost-effective measures to reduce those risks. See Requirements Analysis Phase.

Security Test - A formal test performed on an operational system, based on the results of the security risk assessment in order to evaluate compliance with security and data integrity guidelines, and address security backup, recovery, and audit trails. Also called Security Testing and Evaluation (ST&E).

Segment - A major part of a larger system or subsystem; in software, a self-contained portion of a computer program.

Sensitive System - A system or subsystem that requires an IT Systems Security Certification and Accreditation; contains data requiring security safeguards.

Sensitivity Analysis - Assesses the potential effect on inputs (costs) and outcomes (benefits) that depends on the relative magnitude of change in certain factors or assumptions.

Software - Computer programs (code), procedures, documentation, and data pertaining to the operation of a computer system. Compare to Hardware.

Software Development Document - Contains all of the information pertaining to the development of each unit or module, including the test cases, software, test results, approvals, and any other items that will help explain the functionality of the software.

Standard - Mandatory requirements to prescribe a disciplined uniform approach to software development and maintenance activities.



QPM #

AQS 200-001-WI

Revision

1


Subsystem - A collection of components that meets the definition of a system, but is considered part of a larger system. See System.

Survivability - A measure of the ability of a system to continue to function, especially in the presence of errors.

System - A collection of components (hardware, software, interfaces) organized to accomplish a specific function or set of functions; generally considered to be a self-sufficient item in its intended operational use.

System Administrator - The person responsible for planning a system installation and use of the system by other users.

System Boundary Document - A formal document created during the System Concept Development Phase that lists the business case for initiating the system or project. It contains responsible persons, projected costs associated with the investment, risks, assumptions, scope, schedule, milestones, etc.

System Component - Any of the discrete items that comprise a system or subsystem. See Subsystem, System.

System Change Request - The formal Change Control Document procedure used to request a change to a system baseline, provide information concerning the requested change, and act as the documented approval mechanism for the change. See Change Control Documents.

System Concept Development Phase - Phase that starts the life cycle; begins when a need to develop or significantly change a system is identified, then the approaches for meeting this need are reviewed for feasibility and appropriateness (for example, cost-benefit analysis).

System Design Document - A formal document that describes the system architecture, file and database design, interfaces, and detailed hardware/software design; used as the baseline for system development.

Systems of Records Notice - Notice that is required to be published for any system that has been determined to be an official System of Records (in terms of the criteria established by the Privacy Act).

System Proponent - The organization benefiting from or requesting the project; frequently thought of as the "customer" for that project.

Systems Administration Manual - A manual that serves the purpose of an Operations Manual in a distributed (client/server) application. See Operations Manual, Client/Server.

Systems Analysis - In systems development, the process of studying and understanding the requirements (customer needs) for a system in order to develop a feasible design.

Systems Development Life Cycle - A formal model of a hardware/software project that depicts the relationship among activities, products, reviews, approvals, and resources. Also, the period of time that begins when a system is conceived (system concept development) and ends when the system is no longer available for use (disposition).



QPM #

AQS 200-001-WI

Revision

1


Systems Manager - The individual, or group, responsible for post-implementation system maintenance, configuration management, change control, and release control. This may or may not include members of the development team.

System Security Plan - A formal document that establishes the processes and procedures for identifying all areas where security could be compromised within the system (or subsystem).

System Software - Software designed to facilitate the operation of a computer system and associated computer programs (for example, operating systems, code compilers, utilities). Compare to Application Software.

System Test - The process of testing an integrated hardware/software system to verify that the system meets its documented requirements.

-T-Tailor - A formal procedure to modify a process, standard, procedure, or work pattern to fit a specific use or business need.

Target - The computer that is the destination for a host communication; See Host. In programming, a language into which another language is to be translated.

Task - In project management, the smallest unit of work subject to management accountability; a work assignment for one or more project members fulfilling a role, as defined in a work breakdown structure.

Technical - Relating to agreements, conditions, and/or requirements affecting the functionality and operation of a system. Compare to non-technical.

Test - The process of exercising the product to identify differences between expected and actual results and performance. Typically testing is bottom-up: unit test, integration test, system test, and acceptance test.

Test Case - A specific set of test data and associated procedures developed for a particular test.

Test Files/Data - Files/data developed for the purpose of executing a test; becomes part of a test case. See Test Case.

Testability - A metric used to measure the characteristics of a requirement that enable it to be verified during a test.

Test Analysis Approval Determination - The form attached to the Test Analysis Report as a final result of the test reviews for all testing levels above the Integration test. See Test Analysis Report.

Test Analysis Report - Formal documentation of the software testing as defined in the Test Plan.

Test and Evaluation (T&E) - T&E occurs during all major phases of the development life cycle, beginning with system planning and continuing through the operations and maintenance phase, ensures standardized identification, refinement, and traceability of the requirements as such requirements are allocated to the system components.



QPM #

AQS 200-001-WI

Revision

1


Test and Evaluation Master Plan - The formal document that identifies the tasks and activities so the entire system can be adequately tested to assure a successful implementation.

Test Problem Report - Formal documentation of problems encountered during testing; the form is attached to the Test Analysis Report. See Test Analysis Report.

Test Readiness Review - A formal phase review to determine that the test procedures are complete and to ensure that the system is ready for formal testing.

Tools - Software application products that assist in the design, development, and coding of software. Also called CASE tools; see Computer-aided Software Engineering.

Top-down - An approach that takes the highest level of a hierarchy and proceeds through progressively lower levels; compare to Bottom-up.

Traceability - In requirements management, the identification and documentation of the derivation path (upward) and allocation path (downward) of requirements in the hierarchy.

Training - The formal process of depicting, simulating, or portraying the operational characteristics of a system or system component in order to make someone proficient in its use.

Training Plan - A formal document that outlines the objectives, needs, strategy, and curriculum to be addressed for training users of the new or enhanced system.

-U-Unit - the smallest logical entity specified in the design of a software system; must be of sufficient detail to allow the code to be developed and tested independent of other units. See Module.

Unit Test - In testing, the process of ensuring that the software unit executes as intended; usually performed by the developer.

Upgrade - A new release of a software system for the purpose of including a new version of one or more system components.

Usability - The capability of the software product to be understood, learned, used and of value to the user, when used under specified conditions.

User - An individual or organization that operates or interacts directly with the system; one who uses the services of a system. The user may or may not be the customer. See Customer.

User Acceptance Test - Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the user to determine whether or not to accept the system. See Acceptance Test.

User Interface - The software, input/output (I/O) devices, screens, procedures, and dialogue between the user of the system (people) and the system (or system component) itself. See Interface.

User Manual - A formal document that contains all essential information for the user to make full use of the new or upgraded system.



QPM #

AQS 200-001-WI

Revision

1


User Satisfaction Review - A formal survey used to gather the data needed to analyze current user satisfaction with the performance capabilities of an existing system or application; administered annually, or as needed.

-V-Validation - The process of determining the correctness of the final product, system, or system component with respect to the user's requirements. Answers the question, "Am I building the right product?" Compare to Verification.

Verifiability - A measure of the relative effort to verify a requirement; a requirement is verifiable only if there is a finite cost-effective process to determine that the software product or system meets the requirement.

Verification - The process of determining whether the products of a life cycle phase fulfill the requirements established during the previous phase; answers the question, "Am I building the product right?" Compare to Validation.

Verification and Validation Plan - A formal document that describes the process to verify and validate the requirements. Created during the Planning Phase and updated throughout the SDLC.

Version - An initial release or re-release of a computer software configuration item, associated with a complete compilation or recompilation of the computer software configuration item; sometimes called a build. See Build.

Version Description Document - A formal document that describes the exact version of a configuration item and its interim changes. It is used to identify the current version; provides a "packing list" of what is included in the release.

Volatility - In requirements management, the degree to which requirements are expected to change throughout the systems development life cycle; opposite of stability.

-W-Walk-through - A software inspection process, conducted by peers of the software developer, to evaluate a software component. See Inspection, Peer Review.

Work Breakdown Structure - In project management, a hierarchical representation of the activities associated with developing a product or executing a process; a list of tasks; often used to develop a Gantt Chart.

Work Pattern - The complete set of life cycle phases, activities, deliverables, and reviews required to develop or maintain a software product or system; a formal approach to systems development.



QPM #

AQS 200-001-WI

Revision

1


52 ACRONYMS

-A-ABL Allocated Baseline

ACSN Advanced Change Study Notice

ADP Automated Data Processing

AIS Automated Information System

APB Acquisition Project Baseline

-B-BPR Business Process Reengineering

-C-CASE Computer-Aided Software Engineering

CBA Cost-Benefit Analysis

CD-ROM Compact Disk-Read Only Memory

CI Configuration Item

CM Configuration Management

CMM Capability Maturity Model

COCOMO Constructive Cost Model

CONOPS Concept of Operations

COTR Contracting Officers' Technical Representative

COTS Commercial Off-The-Shelf

CRUD Create, Read, Update, Delete

CSA Configuration Status Accounting

CSCI Computer Software Configuration Items

CWBS Contract Work Breakdown Structure

-D-DBA Database Administrator

DBMS Database Management System

-E-ECP Engineering Change Proposal



QPM #

AQS 200-001-WI

Revision

1


-F-FAA AMS Federal Aviation Administration Acquisition Management System

FAR Federal Acquisition Regulations

FASA Federal Acquisition Streamlining Act

FBL Functional Baseline

FCA Functional Configuration Audit

FIPS Federal Information Processing Standards

FOIA/PA Freedom of Information Act/Privacy Act

FRD Functional Requirements Document

-G-GAO General Accounting Office

GPRA Government Performance and Results Act

GUI Graphical User Interface

-H-HCI Hardware Configuration Items

-I-ICD Interface Control Document

IEEE/EIA Institute of Electrical and Electronics Engineers/Electronic Industries Assoc.

IMSS Information Management and Security Staff

IPT Integrated Product Team

IRM Information Resources Management

ISSM Information Systems Security Manager

ISO International Standard Organization

IT Information Technology

ITA Information Technology Architecture

ITIB Information Technology Investment Board

-J-JCL Job Control Language

-L-LAN Local Area Network



QPM #

AQS 200-001-WI

Revision

1


-O-OBDB Offices, Boards, Divisions and Bureaus

OMB Office of Management and Budget

-P-PBL Product Baseline

PCA Physical Configuration Audit

PERT Program Evaluation Review Technique

PRRA Paperwork Reduction Reauthorization Act

-Q-QA Quality Assurance

QAR Quality Action Report

-R-RM Risk Management

RTM Requirements Traceability Matrix

-S-SBD System Boundary Document

SBU Sensitive-but-Unclassified

SCAP Security Certification and Accreditation Package

SCR System Change Request

SDLC Systems Development Life Cycle

SEI Software Engineering Institute

SEMP Systems Engineering Management Plan

SLIM Software Life Cycle Management

SOW Statement of Work

SPM Systems Program Manager

ST&E Security Test and Evaluation

-T-TAAD Test Analysis Approval Determination

T&E Test and Evaluation

TIM Technical Interchange Meetings

TPM Technical Performance Measurement



QPM #

AQS 200-001-WI

Revision

1


TRM Technical Reference Model

-V-VDD Version Description Document

V&V Verification and Validation

-W-WBS Work Breakdown Structure



QPM #

AQS 200-001-WI

Revision

1


Please submit any written comments or recommendations for improving this directive, or suggest new items or subjects to be added to it. Also, if you find an error, please tell us about it.

Subject: SDLC Document

To: SDLC Management Officer, AQS-200

(Please check all appropriate line items)

An error (procedural or typographical) has been noted in paragraph __________ on

page ________________.

Recommend paragraph ________________ on page _______________ be changed as follows:

(attach separate sheet if necessary)

In a future change to this directive, please include coverage on the following subject

(Briefly describe what you want added):

Other comments:UNCONTROLLED COPY WHEN DOWNLOADED



QPM #

AQS 200-001-WI

Revision

1


I would like to discuss the above. Please contact me.

Submitted by: __________________________________ Date: _______________

FTS Telephone Number: _________________________ Routing Symbol: ___________

FAA Form 1320-19 (8-89)
