AQS-200 SDLC Work Instruction by MNNn61

VIEWS: 67 PAGES: 350

									                                                                                                Revision
                        AVS                                                 QPM #
                                                                                                   1
             Quality Management System                                 AQS 200-001-WI

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




                                      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 DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                          AVS                                             QPM #
                                                                                                 1
               Quality Management System                             AQS 200-001-WI

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




                                      REVISION HISTORY
         Rev                     Description of Change                     Effective Date
                  Original
          0       Formatted to comply with the AVS process                    06/28/06
                  template and link to the AQS-200-001 process
          1         Updated to reference AQS-200-001 WI 4,
                    Process Lifecycle Process and explicitly state                2/5/07
                    that it is guidance




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                 Revision
                        AVS                                                                          QPM #
                                                                                                                                      1
             Quality Management System                                                        AQS 200-001-WI

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

                                                       TABLE OF CONTENTS


    0      Executive Summary ...................................................................................................... 1
           0.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 ................................................................................................................... 5
           1.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 ............................................................. 11
           2.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 ......................................................................................... 15
           3.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
           4.1.      Objectives .......................................................................................................... 49
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                Revision
                        AVS                                                                         QPM #
                                                                                                                                     1
             Quality Management System                                                       AQS 200-001-WI

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

           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 ............................................................................................ 56
           5.1.     Objective ............................................................................................................ 56
           5.2.     Tasks and Activities ........................................................................................... 56
           5.3.     Roles and Responsibilities ................................................................................. 59
           5.4.     Deliverables, Responsibilities, and Actions ........................................................ 59
           5.5.     Issues for Consideration .................................................................................... 61
           5.6.     Review Activity ................................................................................................... 61
    6      Phase 3: Requirements Analysis Phase .................................................................... 62
           6.1.     Objective ............................................................................................................ 62
           6.2.     Tasks and Activities ........................................................................................... 62
           6.3.     Roles and Responsibilities ................................................................................. 64
           6.4.     Deliverables, Responsibilities, and Actions ........................................................ 65
           6.5.     Issues for Consideration .................................................................................... 67
           6.6.     Review Activity ................................................................................................... 68
    7      Phase 4: Design Phase ............................................................................................... 69
           7.1.     Objective ............................................................................................................ 69
           7.2.     Tasks and Activities ........................................................................................... 69
           7.3.     Roles and Responsibilities ................................................................................. 71
           7.4.     Deliverables, Responsibilities, and Actions ........................................................ 72
           7.5.     Issues for Consideration .................................................................................... 74
           7.6.     Review Activity ................................................................................................... 75
    8      Phase 5: Development Phase ..................................................................................... 77
           8.1.     Objective ............................................................................................................ 77
           8.2.     Tasks and Activities ........................................................................................... 77
           8.3.     Roles and Responsibilities ................................................................................. 83
           8.4.     Deliverables, Responsibilities and Actions ......................................................... 84
           8.5.     Issues for Consideration .................................................................................... 85
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                Revision
                        AVS                                                                         QPM #
                                                                                                                                     1
             Quality Management System                                                       AQS 200-001-WI

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

           8.6.     Review Activity ................................................................................................... 85
    9      Phase 6: Integration and Test Phase ......................................................................... 86
           9.1.     Objective ............................................................................................................ 86
           9.2.     Tasks and Activities ........................................................................................... 86
           9.3.     Roles and Responsibilities ................................................................................. 87
           9.4.     Deliverables, Responsibilities, and Actions ........................................................ 87
           9.5.     Issues for Consideration .................................................................................... 88
           9.6.     Review Activity ................................................................................................... 89
    10     Phase 7: Implementation Phase ................................................................................. 90
           10.1.    Objective ............................................................................................................ 90
           10.2.    Tasks and Activities ........................................................................................... 90
           10.3.    Roles and Responsibilities ................................................................................. 92
           10.4.    Deliverables, Responsibilities, and Actions ........................................................ 92
           10.5.    Issues for Consideration .................................................................................... 93
           10.6.    Review Activity ................................................................................................... 93
    11     Phase 8: Operations and Maintenance Phase ........................................................... 95
           11.1.    Objective ............................................................................................................ 95
           11.2.    Tasks and Activities ........................................................................................... 95
           11.3.    Roles and Responsibilities ................................................................................. 97
           11.4.    Deliverables, Responsibilities and Action ........................................................... 99
           11.5.    Issues for Consideration .................................................................................... 99
           11.6.    Review Activity ................................................................................................. 100
    12     Phase 9: Disposition Phase ...................................................................................... 101
           12.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 .................................................................................. 104
           12.6.    Review Activity ................................................................................................. 104
    13     Alternative SDLC Work Patterns .............................................................................. 105
           13.1.    Objective .......................................................................................................... 105
           13.2.    Alternative Work Patterns ................................................................................ 105
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                  Revision
                        AVS                                                                           QPM #
                                                                                                                                       1
             Quality Management System                                                         AQS 200-001-WI

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

           13.3.     Alternative Work Pattern Selection ................................................................... 106
           13.4.     Work Pattern Descriptions and Exhibits ........................................................... 109
           13.5.     Additional Work Patterns.................................................................................. 129
    14     System Boundary Document .................................................................................... 130
           14.1.     Format for SBD Cover Memo ........................................................................... 130
           14.2.     The Requirements Document .......................................................................... 130
           14.3.     Traceability ...................................................................................................... 131
           14.4.     Approval .......................................................................................................... 131
           14.5.     Using This Template ........................................................................................ 131
           14.6.     AQS-200-Controlled Parameters ..................................................................... 132
           14.7.     Change Control ................................................................................................ 132
           14.8.     Cost ................................................................................................................. 132
           14.9.     Schedule .......................................................................................................... 132
           14.10. Benefits............................................................................................................ 132
           14.11. Examples of Operational and Functional Requirements ................................... 136
           14.12. Examples of Characteristics and Performance Requirements .......................... 136
           14.13. References ...................................................................................................... 137
    15     Cost-Benefit Analysis ............................................................................................... 139
           15.1.     Overview .......................................................................................................... 139
           15.2.     Objectives and Performance Measures ........................................................... 140
           15.3.     Assumptions, Constraints, and Conditions ....................................................... 141
           15.4.     Feasible Alternatives ........................................................................................ 142
           15.5.     Cost Analysis ................................................................................................... 143
           15.6.     Benefit Analysis ............................................................................................... 144
           15.7.     Comparison of Costs and Benefits ................................................................... 147
           15.8.     Sensitivity Analysis .......................................................................................... 148
           15.9.     Results of the Analysis ..................................................................................... 149
           15.10. References and Documentation ....................................................................... 149
           15.11. Glossary and Acronyms ................................................................................... 149
           15.12. Cost-Benefit Analysis Outline ........................................................................... 150
    16     Feasibility Study ........................................................................................................ 152
           16.1.     Introduction ...................................................................................................... 153
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                Revision
                        AVS                                                                         QPM #
                                                                                                                                     1
             Quality Management System                                                       AQS 200-001-WI

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

           16.2.     Evaluation Criteria............................................................................................ 153
           16.3.     Alternative Descriptions ................................................................................... 153
           16.4.     Alternative Evaluation ...................................................................................... 154
           16.5.     Recommendation ............................................................................................. 154
           16.6.     Feasibility Study Outline................................................................................... 154
    17     Risk Management Plan ............................................................................................. 155
           17.1.     Introduction ...................................................................................................... 155
           17.2.     Risk Identification List ...................................................................................... 155
           17.3.     Risk Assessment ............................................................................................. 156
           17.4.     Risk Action Plan ............................................................................................... 156
           17.5.     Risk Management Outline ................................................................................ 157
    18     Acquisition Plan ........................................................................................................ 158
           18.1.     Background and Objectives ............................................................................. 159
           18.2.     Plan of Action................................................................................................... 161
           18.3.     Acquisition Plan Outline ................................................................................... 163
    19     Configuration Management Plan .............................................................................. 165
           19.1.     Introduction ...................................................................................................... 165
           19.2.     Organization .................................................................................................... 165
           19.3.     Configuration Identification............................................................................... 165
           19.4.     Configuration Control ....................................................................................... 166
           19.5.     Configuration Status Accounting ...................................................................... 166
           19.6.     Configuration Audits......................................................................................... 167
           19.7.     Reviews ........................................................................................................... 167
           19.8.     CM Plan Maintenance ...................................................................................... 167
           19.9.     Data Management ........................................................................................... 167
           19.10. Subcontractor Control ...................................................................................... 167
           19.11. Configuration Management Plan Outline .......................................................... 168
    20     Quality Assurance Plan............................................................................................. 170
           20.1.     General ............................................................................................................ 170
           20.2.     Organization .................................................................................................... 170
           20.3.     Processes ........................................................................................................ 171
           20.4.     Problem Reporting and Corrective Action ........................................................ 171
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                               Revision
                        AVS                                                                         QPM #
                                                                                                                                    1
             Quality Management System                                                       AQS 200-001-WI

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

           20.5.     Tools, Techniques, and Methodologies ............................................................ 172
           20.6.     Quality Assurance Plan Outline........................................................................ 172
    21     Concept of Operations .............................................................................................. 174
           21.1.     Statement of Need ........................................................................................... 174
           21.2.     Organizational Units Impacted (Customers) ..................................................... 174
           21.3.     Work to be Automated ..................................................................................... 174
           21.4.     Costs and Benefits ........................................................................................... 174
           21.5.     Options Considered ......................................................................................... 175
           21.6.     How the Function is Currently Performed ......................................................... 175
           21.7.     Requester’s Name, Routing Symbol and Position ............................................ 175
           21.8.     Concept Paper ................................................................................................. 175
    22     System Security Plan ................................................................................................ 176
    23     Project Management Plan ......................................................................................... 177
           23.1.     Introduction ...................................................................................................... 177
           23.2.     Project Description ........................................................................................... 177
           23.3.     Project Background.......................................................................................... 177
           23.4.     Points of Contact.............................................................................................. 177
           23.5.     Project References .......................................................................................... 177
           23.6.     Glossary .......................................................................................................... 178
           23.7.     Organization And Responsibilities .................................................................... 178
           23.8.     Project Description, Schedule and Resources ................................................. 178
           23.9.     Security and Privacy ........................................................................................ 181
           23.10. Project Management Plan Outline .................................................................... 181
    24     Verification and Validation Plan ............................................................................... 183
           24.1.     Background and Introduction ........................................................................... 183
           24.2.     V&V Requirements and Measurement Criteria ................................................. 183
           24.3.     Phase by Phase V&V Plans ............................................................................. 183
           24.4.     Verification and Validation Plan Outline ........................................................... 184
    25     Systems Engineering Management Plan ................................................................. 186
           25.1.     Introduction ...................................................................................................... 186
           25.2.     System Engineering Process ........................................................................... 186
           25.3.     Technology Refreshment ................................................................................. 188
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                 Revision
                        AVS                                                                          QPM #
                                                                                                                                      1
             Quality Management System                                                        AQS 200-001-WI

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

           25.4.     Implementation Planning.................................................................................. 188
           25.5.     Specialty Engineering Planning........................................................................ 188
           25.6.     Systems Engineering Management Plan Outline ............................................. 188
    26     Functional Requirements Document ....................................................................... 190
           26.1.     Introduction ...................................................................................................... 190
           26.2.     Functional Requirements ................................................................................. 192
           26.3.     Operational Requirements ............................................................................... 192
           26.4.     Requirements Traceability Matrix ..................................................................... 195
           26.5.     Glossary .......................................................................................................... 195
           26.6.     Functional Requirements Document Outline .................................................... 195
    27     Test and Evaluation Master Plan .............................................................................. 197
           27.1.     Introduction ...................................................................................................... 197
           27.2.     Purpose ........................................................................................................... 197
           27.3.     Background...................................................................................................... 197
           27.4.     Scope .............................................................................................................. 197
           27.5.     Glossary .......................................................................................................... 198
           27.6.     Limitations and Traceability .............................................................................. 198
           27.7.     Test Plans ........................................................................................................ 198
           27.8.     Test Description ............................................................................................... 201
           27.9.     Test and Evaluation Master Plan Outline ......................................................... 202
    28     Interface Control Document ..................................................................................... 204
           28.1.     Scope .............................................................................................................. 204
           28.2.     System Identification ........................................................................................ 204
           28.3.     Document Overview ......................................................................................... 204
           28.4.     Applicable Documents ..................................................................................... 205
           28.5.     Description ....................................................................................................... 205
           28.6.     Detailed Interface Requirements ...................................................................... 206
           28.7.     Qualification Methods ...................................................................................... 209
           28.8.     Notes ............................................................................................................... 210
           28.9.     Appendices ...................................................................................................... 210
           28.10. Approvals ......................................................................................................... 210
           28.11. Record of Changes .......................................................................................... 210
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                Revision
                        AVS                                                                         QPM #
                                                                                                                                     1
             Quality Management System                                                       AQS 200-001-WI

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

           28.12. Interface Control Document Outline ................................................................. 210
    29     Security Risk Assessment ........................................................................................ 212
    30     Contingency Plan ...................................................................................................... 213
    31     Conversion Plan ........................................................................................................ 214
           31.1.     Introduction ...................................................................................................... 214
           31.2.     Conversion Overview ....................................................................................... 214
           31.3.     Conversion Support ......................................................................................... 218
           31.4.     Conversion Plan Outline .................................................................................. 219
    32     System Design Document ........................................................................................ 221
           32.1.     Introduction ...................................................................................................... 221
           32.2.     System Architecture ......................................................................................... 222
           32.3.     File and Database Design ................................................................................ 222
           32.4.     Human-Machine Interface ................................................................................ 223
           32.5.     Detailed Design ............................................................................................... 224
           32.6.     External Interfaces ........................................................................................... 226
           32.7.     System Integrity Controls ................................................................................. 227
           32.8.     Design Document Outline ................................................................................ 228
    33     Implementation Plan ................................................................................................. 230
           33.1.     Introduction ...................................................................................................... 230
           33.2.     Management Overview .................................................................................... 231
           33.3.     Implementation Support ................................................................................... 232
           33.4.     Implementation Requirements by Site.............................................................. 234
           33.5.     Implementation Plan Outline ............................................................................ 236
    34     Maintenance Manual ................................................................................................. 238
           34.1.     Introduction ...................................................................................................... 238
           34.2.     System Description .......................................................................................... 238
           34.3.     Support Environment ....................................................................................... 239
           34.4.     System Maintenance Procedures .................................................................... 240
           34.5.     Software Unit Maintenance Procedures ........................................................... 241
           34.6.     Maintenance Manual Outline ........................................................................... 242
    35     Operations Manual .................................................................................................... 243
           35.1.     General ............................................................................................................ 243
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                Revision
                        AVS                                                                         QPM #
                                                                                                                                     1
             Quality Management System                                                       AQS 200-001-WI

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

           35.2.     System Overview ............................................................................................. 243
           35.3.     Description of Runs.......................................................................................... 244
           35.4.     Operations Manual Outline .............................................................................. 245
    36     System Administration Manual ................................................................................ 247
           36.1.     General ............................................................................................................ 247
           36.2.     System Overview ............................................................................................. 247
           36.3.     Site Profile(s) ................................................................................................... 248
           36.4.     Systems Administration.................................................................................... 248
           36.5.     Systems Administration Manual Outline ........................................................... 252
    37     Training Plan.............................................................................................................. 256
           37.1.     Introduction ...................................................................................................... 256
           37.2.     Requirements Traceability ............................................................................... 257
           37.3.     Instructional Analysis ....................................................................................... 257
           37.4.     Instructional Methods ....................................................................................... 257
           37.5.     Training Resources .......................................................................................... 258
           37.6.     Training Curriculum.......................................................................................... 259
           37.7.     Training Plan Outline ....................................................................................... 259
    38     User Manual ............................................................................................................... 261
           38.1.     Introduction ...................................................................................................... 261
           38.2.     System Capabilities ......................................................................................... 261
           38.3.     Description of System Functions ...................................................................... 262
           38.4.     Operating Instructions ...................................................................................... 263
           38.5.     Error Handling .................................................................................................. 264
           38.6.     User Manual Outline ........................................................................................ 264
    39     Software development Document ............................................................................ 266
           39.1.     1.0 Introduction ................................................................................................ 266
           39.2.     2.0 Roles and Responsibilities ......................................................................... 266
           39.3.     Software Development Folder Check-Off Sheet ............................................... 267
    40     Integration Document ............................................................................................... 269
           40.1.     Introduction ...................................................................................................... 269
           40.2.     Management Overview .................................................................................... 270
           40.3.     Integration Support .......................................................................................... 270
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                Revision
                        AVS                                                                         QPM #
                                                                                                                                     1
             Quality Management System                                                       AQS 200-001-WI

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

           40.4.     Integration Document Outline........................................................................... 271
    41     Test Analysis Report ................................................................................................. 273
           41.1.     Purpose ........................................................................................................... 273
           41.2.     Scope .............................................................................................................. 273
           41.3.     Reference Documents ..................................................................................... 273
           41.4.     Test Analysis ................................................................................................... 274
           41.5.     Software and Hardware Requirements Findings .............................................. 274
           41.6.     Summary and Conclusions .............................................................................. 275
           41.7.     Test Analysis Report Outline ............................................................................ 276
    42     Test Analysis Approval Determination .................................................................... 277
           42.1.     Test Analysis Approval Determination Outline (Non-Mainframes ) ................... 277
           42.2.     Test Analysis Approval Determination (For Mainframes).................................. 277
    43     Test Problem Reports ............................................................................................... 279
           43.1.     Test Problem Report Outline ............................................................................ 279
    44     Change Implementation Notice ................................................................................ 280
    45     Version Description Document ................................................................................ 281
           45.1.     Introduction ...................................................................................................... 281
           45.2.     Scope .............................................................................................................. 281
           45.3.     Reference Documents ..................................................................................... 282
           45.4.     Version Description .......................................................................................... 282
           45.5.     Appendices ...................................................................................................... 283
           45.6.     Version Description Document Outline............................................................. 283
           45.7.     Version Description Document Contents .......................................................... 284
    46     Post-Implementation Review Report........................................................................ 286
           46.1.     Introduction ...................................................................................................... 286
           46.2.     Evaluation Summary ........................................................................................ 286
           46.3.     Analysis and Implementation ........................................................................... 287
           46.4.     Outputs ............................................................................................................ 289
           46.5.     Security............................................................................................................ 289
           46.6.     Computer Operations ....................................................................................... 291
           46.7.     Maintenance Activities ..................................................................................... 292
           46.8.     Post-implementation Review Report Outline .................................................... 292
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                Revision
                        AVS                                                                          QPM #
                                                                                                                                     1
             Quality Management System                                                        AQS 200-001-WI

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

    47     Periodic System Review Report ............................................................................... 294
           47.1.     Introduction ...................................................................................................... 294
           47.2.     Review Process ............................................................................................... 294
           47.3.     Findings ........................................................................................................... 297
           47.4.     Recommendations ........................................................................................... 297
           47.5.     Approvals and Appendices .............................................................................. 297
           47.6.     Periodic System Review Report Outline ........................................................... 298
    48     User Satisfaction Review .......................................................................................... 299
           48.1.     Introduction ...................................................................................................... 299
           48.2.     Roles and Responsibilities ............................................................................... 299
           48.3.     Process............................................................................................................ 299
           48.4.     User Satisfaction Review Outline ..................................................................... 301
    49     Disposition Plan ........................................................................................................ 304
           49.1.     Introduction ...................................................................................................... 305
           49.2.     System Disposition .......................................................................................... 306
           49.3.     Project Closedown ........................................................................................... 306
           49.4.     Disposition Plan Outline ................................................................................... 306
    50     Post-Termination Review Report ............................................................................. 308
           50.1.     Introduction ...................................................................................................... 308
           50.2.     Lessons Learned ............................................................................................. 308
           50.3.     Archiving .......................................................................................................... 309
           50.4.     Post-Termination Review Report Outline ......................................................... 309
    51     Information Security Requirements ......................................................................... 310
    52     Glossary ..................................................................................................................... 315
    53     Acronyms ................................................................................................................... 332




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                          AVS                                             QPM #
                                                                                                 1
               Quality Management System                             AQS 200-001-WI

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


    0      EXECUTIVE SUMMARY

    0.1.   THE SYSTEM DEVELOPMENT LIFE CYCLE
    The 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 APPLICABILITY
    The 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 14.
    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 BENEFITS
    This 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;
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                          AVS                                             QPM #
                                                                                                   1
               Quality Management System                             AQS 200-001-WI

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


                  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 PRINCIPLES
    This 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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                        AVS                                                  QPM #
                                                                                                        1
             Quality Management System                                  AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07             Page 3 of 350

           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,
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                   Revision
                        AVS                                                  QPM #
                                                                                                      1
             Quality Management System                                  AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07             Page 4 of 350

           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.



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                              QPM #
                                                                                                 1
              Quality Management System                               AQS 200-001-WI

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


    1        INTRODUCTION

    1.1.     BACKGROUND
    AVS 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.
    1.2.     PURPOSE, SCOPE, AND APPLICABILITY
    1.2.1.         PURPOSE
    This 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.
    1.2.2.         SCOPE
    This 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 14 and subsequent sections should be tailored
    based on the scope of the effort and the needs of the decision authorities.
    1.2.3.         APPLICABILITY
    This methodology can be applied to all AVS offices that are responsible for information systems
    development.
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                          Revision
                         AVS                                                        QPM #
                                                                                                              1
              Quality Management System                                       AQS 200-001-WI

Title: System Development Lifecycle                                         Date: 2/5/07               Page 6 of 350


    1.2.4.         REFERENCES
    Standard for Information Technology — Software life cycle processes – IEEE Standard
    12207.0-2 dated 1996.
    1.3.     INTRODUCTION TO SDLC
    The 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

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

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

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

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

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

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


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                      Revision
                        AVS                                                      QPM #
                                                                                                         1
             Quality Management System                                     AQS 200-001-WI

Title: System Development Lifecycle                                      Date: 2/5/07              Page 7 of 350


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


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


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




    FIGURE 1-2: PHASE INTERACTION




    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.


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                        AVS                                               QPM #
                                                                                                 1
             Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07            Page 8 of 350


    1.3.1.         SYSTEM CONCEPT DEVELOPMENT PHASE
    System (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.
    1.3.2.         PLANNING PHASE
    A 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.
    1.3.3.         REQUIREMENTS ANALYSIS PHASE
    Functional 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.
    1.3.4.         DESIGN PHASE
    The 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.
    1.3.5.         DEVELOPMENT PHASE
    The 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.
    1.3.6.         INTEGRATION AND TEST PHASE
    Subsystem 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.
    1.3.7.         IMPLEMENTATION 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.
    This phase continues until the system is operating in production in accordance with the defined
    user requirements.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07           Page 9 of 350


    1.3.8.           OPERATIONS AND MAINTENANCE PHASE
    The 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.
    1.3.9.           DISPOSITION PHASE
    The 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.
    1.4.     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.
    1.5.     DOCUMENTATION
    This 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:
    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.


                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                        AVS                                              QPM #
                                                                                                1
             Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                               Date: 2/5/07           Page 10 of 350

    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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                        AVS                                               QPM #
                                                                                                1
             Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 11 of 350


    2      STRATEGIC PLANNING FOR INFORMATION SYSTEMS

    2.1.   STRATEGIC PLANNING
    Strategic 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.
    2.2.   IRM PLANNING FOR INFORMATION SYSTEMS
    AVS 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.
    2.3.   PERFORMANCE MEASUREMENT
    Performance 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
    measurement systems. A major step toward measuring results was the passage of the Chief

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                  1
             Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 12 of 350

    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.
    2.4.   BUSINESS PROCESS REENGINEERING
    Business 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
    organizations and customers, electronically, also makes it increasingly important that standard

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                 1
             Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 13 of 350

    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.
    2.5.   QUALITY IMPROVEMENT PROCESS AND THE LIFE CYCLE
    Quality 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.
    2.6.   BUDGET FORMULATION FOR SYSTEMS INITIATIVES
    AVS 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


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                 1
             Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 14 of 350

    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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07            Page 15 of 350


    3      KEY SUPPORTING PROCESSES

    3.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.
    3.2.   PROJECT PLANNING
    For 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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07          Page 16 of 350


                    Acquisition Strategy Paper
                    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.
    3.2.1.           ORGANIZATIONAL DEVELOPMENT
    Development 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.
    3.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.
    3.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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07            Page 17 of 350

    selected for the project. Selecting an acquisition strategy that requires skills and experience not
    present in the available staffing introduces major risks.
    3.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.
    3.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.
    3.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.
    3.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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                     Revision
                            AVS                                                QPM #
                                                                                                         1
                 Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                     Date: 2/5/07               Page 18 of 350

    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
    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

    3.2.2.           ACQUISITION STRATEGY DEVELOPMENT
    Acquisition 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.
    3.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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                    Revision
                          AVS                                                               QPM #
                                                                                                                       1
               Quality Management System                                               AQS 200-001-WI

Title: System Development Lifecycle                                                  Date: 2/5/07              Page 19 of 350


                    Urgency of business need
                    Maturity of organizational processes
    The key to all strategy decisions should be a balance of acquisition risk against the verified
    business need as illustrated in Figure 3-1. 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-1: ACQUISITION STRATEGY DECISION CONCEPT


                 Areas of Concern           Business Need                  Choices                  Business Need
                                                                                                      Urgency
                                                                                                      Complexity
         Technical            Resources                     Alternatives         Opportunities      Technical
                                                                                                      Available Technology
                                                                                                      System Interfaces
                                                                                                    Resources
                                                                                                      Budget
                                                                                                      Schedule
                                              Risk                                                    Personnel
                                                                                                    Alternatives
                                                                                                       Culture
                                                                                                       Amount of Oversight
                                                                                                    Opportunities
                                    Acquisition Strategy Decisions                                    Political Support
                                                                                                      Available Resources


                                           Execution Plans

    3.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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                          AVS                                             QPM #
                                                                                                 1
               Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07          Page 20 of 350


                  Special Permissions and Waivers Needed
                  Records disposition, Privacy Act, Freedom of Information Act, and other legal
                   considerations
                  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.)
    3.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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                   Revision
                            AVS                                               QPM #
                                                                                                       1
                 Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07               Page 21 of 350


                    The system design needs to remain constant due to cost or schedule constraints.
    3.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-1: Acquisition Strategy Decision Concept should be
    maintained, with all elements being adjusted until a balance is again reached.
    3.2.3.           PROJECT SCHEDULE DEVELOPMENT
    Schedule 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.
    3.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)


                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                     Revision
                          AVS                                                  QPM #
                                                                                                         1
               Quality Management System                                   AQS 200-001-WI

Title: System Development Lifecycle                                     Date: 2/5/07               Page 22 of 350


                                        Best Practices: Acquisition Strategy

               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



    3.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.
    3.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.


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                                                         Revision
                        AVS                                                                                  QPM #
                                                                                                                                                                                    1
             Quality Management System                                                             AQS 200-001-WI

Title: System Development Lifecycle                                                           Date: 2/5/07                                                          Page 23 of 350


    3.2.4.         PROJECT PLANNING ACTIVITIES
    Acquisition 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-2.
    FIGURE 3-2: PLANNING DOCUMENTS




                                                                                                                        Integration and Test
                                              System Concept




                                                                                                                                                   Implementation

                                                                                                                                                                    Operation and
                                                                           Requirements
                                              Development




                                                                                                      Development




                                                                                                                                                                    Maintenance

                                                                                                                                                                                        Disposition
                                                                Planning


                                                                           Analysis

                                                                                          Design
    Planning Document
    System Boundary Document                  C/F              *           *              *         *               *                          *
    Cost Benefit Analysis                     C                R           R              R         R               F
    Feasibility Study                         C                R           F
    Risk 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               F
    Systems Engineering Management Plan                        C/F         *              *         *               *                          *                    *               *
    Functional Requirements Document                                       C              F
    Test and Evaluation Master Plan                                        C              R         R               F                          *                    *
    Interface Control Document                                             C              R         R               R                          R                    R
    Privacy Ad Notice                                                      C              F
    Records 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               F
    Maintenance 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                    *

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                                                        Revision
                           AVS                                                                                 QPM #
                                                                                                                                                                                   1
                Quality Management System                                                            AQS 200-001-WI

Title: System Development Lifecycle                                                           Date: 2/5/07                                                         Page 24 of 350




                                                                                                                       Integration and Test
                                                 System Concept




                                                                                                                                                  Implementation

                                                                                                                                                                   Operation and
                                                                             Requirements
                                                 Development




                                                                                                        Development




                                                                                                                                                                   Maintenance

                                                                                                                                                                                       Disposition
                                                                  Planning


                                                                             Analysis

                                                                                            Design
    Planning Document
    Test Files / Data                                                                                 C               F                                            *
    Integration Document                                                                              C               R                       F
    Test Analysis Report                                                                              C               F                                            *
    Test Analysis Approval Determination                                                                              C/F                                          *
    Test Problem Reports                                                                                              C                                            C
    Security Certification and Accreditation                                                                          C/F                     *                    *
    Delivered System Documentation                                                                                                            C/F                  *
    Change Implementation Notice                                                                                                              C                    C
    Version Description Document                                                                                                              C/F                  *
    Post-Implementation Review Report                                                                                                         C
    Periodic System Review Report                                                                                                                                  C
    User Satisfaction Review                                                                                                                                       C
    Disposition Plan                                                                                                                                                               C/F
    Post-Termination Review Report                                                                                                                                                 C/F
    Key:        C=Create      R=Revised        F=Finalized                     * = Update if needed



    3.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

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                    Revision
                           AVS                                                                            QPM #
                                                                                                                                          1
                Quality Management System                                                          AQS 200-001-WI

Title: System Development Lifecycle                                                             Date: 2/5/07                    Page 25 of 350

    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-3 for examples of project management planning needs.
    FIGURE 3-3: PROJECT MANAGEMENT PLANNING

                                Project Management Planning

                                                                                            Project Planning




                                   Project Management Planning




                 Project WBS Planning               Acquisition Program Baseline Planning



         Acquisition Strategy Project Planning          Project Organization Planning



            Management Process Planning                 Scheduling Process Planning



           Requirements Process Planning                     Interface Planning



               Risk Management Planning                      Measures Planning




                       Technical Management Planning             Business Management Planning              Contract Management Planning




    3.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-4.




                               UNCONTROLLED COPY WHEN DOWNLOADED
                  Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                           Revision
                          AVS                                                                                   QPM #
                                                                                                                                                1
               Quality Management System                                                              AQS 200-001-WI

Title: System Development Lifecycle                                                                Date: 2/5/07                        Page 26 of 350

                                FIGURE 3-4: TECHNICAL MANAGEMENT PLANNING HIERARCHY

                                                    Technical Management Planning

                                                                   Project Planning

                          Project Management
                                Planning



                                           Technical Management           Business Management          Contract Management
                                                 Planning                       Planning                     Planning



                                            System Engineering
                                           Management Planning

               Technical Risk
            Management Planning



                    Engineering Development
                                                                                                                Transition Planning
                           Planning



          Quality Assurance           Data Management
                                                                                              Deployment Planning          Data Conversion Planning
              Planning                    Planning


          Technical Review
                                    Supportability Planning                                     Facilities Planning
              Planning


           Requirements                Configuration
        Management Planning         Management Planning


        Specialty Engineering      System Work Breakdown
              Planning                Structure Planning


        Technical Performance
        Measurement Planning



                                    Operations Planning                                                    Interface Planning




                                                    Operations Staffing                     Communications                Interface Standards
                       Training Planning
                                                        Planning                               Planning                         Planning


                     Maintenance Staffing          Technical Refreshment                                                  System-of-Systems
                                                                                            Security Planning
                           Planning                      Planning                                                        Integration Planning




                                                                      Test and Evaluation
                                                                            Planning



                                                     Laboratory Test Planning      Operational Test Planning


                                                        Verification and              Contractor Conducted
                                                       Validation Planning               Test Planning




    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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                        Revision
                          AVS                                                                    QPM #
                                                                                                                               1
               Quality Management System                                                   AQS 200-001-WI

Title: System Development Lifecycle                                                     Date: 2/5/07                 Page 27 of 350

    part of the solicitation package with a corresponding contractor SEMP delivered prior to source
    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).
    3.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-5.
    FIGURE 3-5: BUSINESS MANAGEMENT PLANNING

                                           Business Management Planning


                                                           Project Planning




                     Project Management Planning




          Technical Management Planning            Business Management Planning                 Contract Management Planning




                                Cost Estimating Planning                      Budget Formulation Planning



                             Financial Management Planning                Schedule Management Planning



                                  Reporting Planning                    Policy / Procedure Waiver Planning



                                   GFI / GFE Planning                         Support Contractor Planning



                             Earned Value Program Planning                     Business Metrics Planning



                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                                                             Revision
                            AVS                                                                               QPM #
                                                                                                                                                   1
                 Quality Management System                                                               AQS 200-001-WI

Title: System Development Lifecycle                                                                    Date: 2/5/07                     Page 28 of 350

    3.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-6.
    FIGURE 3-6: CONTRACT MANAGEMENT PLANNING

                                            Contract Management Planning


                                                          Project Planning




                      Project Management Planning




           Technical Management Planning            Business Management Planning               Contract Management Planning




                                                                         Source Selection Planning                    Statement of Work Planning



                                                                             Model Contract Planning                    Fee Structure Planning



                                                                     Subcontract Management Planning            Contract Modification Strategy Planning



                                                                       Contract Management Planning                     O&M Contract Planning



                                                                             COTS Strategy Planning                Certification and Audit Planning




    3.3.       REQUIREMENTS MANAGEMENT
    A 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

                                UNCONTROLLED COPY WHEN DOWNLOADED
                   Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                              QPM #
                                                                                                    1
                 Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07           Page 29 of 350

    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.
    3.3.1.           IDENTIFYING THE REQUIREMENTS OWNER
    As 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



    3.3.2.           IDENTIFYING THE REQUIREMENTS
    Using 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).
    3.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
                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07          Page 30 of 350

    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.
    3.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.
    3.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.


    3.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-7.
    FIGURE 3-7: REQUIREMENT ATTRIBUTES

                          Complete                 Formal                  Simple

                          Consistent               Minimal               Traceable

                           Correct               Modifiable            Unambiguous

                           Feasible             Maintainable              Verifiable

    3.3.3.           CONTROLLING THE REQUIREMENTS
    The 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
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                       Revision
                            AVS                                                  QPM #
                                                                                                          1
                 Quality Management System                                 AQS 200-001-WI

Title: System Development Lifecycle                                      Date: 2/5/07             Page 31 of 350


                    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



    3.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.
    3.3.4.           CHANGING THE REQUIREMENTS
    Needs 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.
                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                            AVS                                               QPM #
                                                                                                     1
                 Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07             Page 32 of 350

    3.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.
    3.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



    3.4.     PROJECT TRACKING AND OVERSIGHT
    All 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.
    3.4.1.           ACQUISITION PROJECT BASELINE DEVELOPMENT
    The 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.
    3.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
                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07            Page 33 of 350

    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.
    3.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.
    3.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.
    3.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.
    3.4.2.         OVERSIGHT ACTIVITIES
    Internal 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.
    3.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.
    3.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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                               QPM #
                                                                                                   1
               Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07            Page 34 of 350

    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.
    3.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.
    3.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.
    3.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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                          AVS                                                  QPM #
                                                                                                   1
               Quality Management System                                  AQS 200-001-WI

Title: System Development Lifecycle                                    Date: 2/5/07         Page 35 of 350

    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.
    3.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




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                  Revision
                            AVS                                               QPM #
                                                                                                      1
                 Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                    Date: 2/5/07            Page 36 of 350


    3.4.3.           PROGRAM/PROJECT TRACKING TOOLS
    3.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.
    3.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).
    3.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 3.5.2.1)




                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07            Page 37 of 350


    3.5.     CONTRACTOR MANAGEMENT
    3.5.1.           PRIME CONTRACTOR MANAGEMENT
    3.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.
    3.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.
    3.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.
    3.5.2.           CONTRACT PERFORMANCE TRACKING
    Contractor 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.
    3.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.


                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07            Page 38 of 350

    3.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.
    3.5.3.         PROJECT SUPPORT CONTRACT MANAGEMENT
    In 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.
    3.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.
    3.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.
    3.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).
    3.5.4.         TECHNICAL CONTRACT MANAGEMENT
    3.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.

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                          AVS                                                QPM #
                                                                                                     1
               Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07            Page 39 of 350

    3.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.
    3.5.5.         FINANCIAL CONTRACT MANAGEMENT
    For 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.
    3.5.6.         CONTRACT CHANGE MANAGEMENT
    Controlling 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.
    3.6.     VALIDATION, VERIFICATION, AND TESTING
    3.6.1.         VALIDATION PROCESS
    The 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.
    3.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.
    3.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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07           Page 40 of 350

    singular conditions. Also, test that representative users can use the software successfully to
    achieve their intended results.
    3.6.2.           VERIFICATION PROCESS
    The 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.
    3.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.
    3.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.
                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                            AVS                                              QPM #
                                                                                                    1
                 Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07            Page 41 of 350


                    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.
    3.6.3.           TEST AND EVALUATION
    Test 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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07           Page 42 of 350


                    The system presents an acceptable risk if placed in operations. This
                     encompasses both business risk as well as information security risk.
    3.7.     QUALITY ASSURANCE
    The 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.
    3.7.1.           PROCESS IMPLEMENTATION
    The 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 20, Quality Assurance Plan.
    3.7.2.           PRODUCT ASSURANCE
    Assure 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.
    3.7.3.           PROCESS ASSURANCE
    Assure 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.
    3.7.4.           ASSURANCE OF QUALITY SYSTEMS
    A 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 need
                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                               QPM #
                                                                                                   1
                 Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                    Date: 2/5/07         Page 43 of 350


                    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.
    3.7.5.           ORGANIZATIONAL ALIGNMENT
    To 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.
    3.8.     CONFIGURATION MANAGEMENT
    All 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.
    3.8.1.           TECHNICAL BASELINE MANAGEMENT
    The 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.
                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                          AVS                                               QPM #
                                                                                                   1
               Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07            Page 44 of 350


                  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.
    3.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.
    3.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.
    3.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.
    3.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.
    3.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-
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                          AVS                                                QPM #
                                                                                                    1
               Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07            Page 45 of 350

    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.
    3.8.2.         CONFIGURATION CONTROL
    Configuration 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).
    3.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.
    3.8.3.         CONFIGURATION STATUS ACCOUNTING
    The 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.
    3.8.4.         CONFIGURATION AUDITS
    A 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.
    3.9.     RISK MANAGEMENT
    Risk 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.


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                    1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07            Page 46 of 350

    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.
    3.9.1.           PROJECT RISK
    3.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.
    3.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.
    3.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.


                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                   Revision
                            AVS                                               QPM #
                                                                                                      1
                 Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                    Date: 2/5/07             Page 47 of 350

    3.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.
    3.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.

    3.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

    3.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.
    3.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.

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                        AVS                                              QPM #
                                                                                                1
             Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                               Date: 2/5/07          Page 48 of 350

    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 51, 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                  1
             Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 49 of 350


    4      PHASE 1: SYSTEM CONCEPT DEVELOPMENT PHASE

    4.1.   OBJECTIVES
    System 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-1).
    FIGURE 4-1: 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

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                QPM #
                                                                                                   1
              Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07            Page 50 of 350

    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.
    4.2.     TASKS AND ACTIVITIES
    The 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-2).
    FIGURE 4-2: SYSTEM CONCEPT DEVELOPMENT PHASE ACTIVITIES




    4.2.1.         REFINE AND STATE THE SYSTEM NEED
    The 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.
    4.2.2.         FORM A PROJECT ORGANIZATION
    This 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.


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                        AVS                                                QPM #
                                                                                                 1
             Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 51 of 350

    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.
    4.2.3.         FORM THE PROJECT ACQUISITION STRATEGY
    The 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 3.2.2 for the
    multiple strategy elements that should be considered during this activity.
    4.2.4.         PLAN THE PROJECT
    The 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.
    4.2.5.         STUDY AND ANALYZE THE STATED NEED
    The 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.
    4.2.6.         STUDY AND ANALYZE THE ACQUISITION RISK
    Concurrent 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.
    4.2.7.         OBTAIN RESOURCES
    Estimate, justify, submit requests for, and obtain resources to execute the project.
    4.2.8.         DOCUMENT THE PHASE EFFORTS
    The results of the phase efforts are documented in the System Boundary Document, Cost
    Benefit Analysis, Feasibility Analysis, and Risk Management Plan.

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                    1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07           Page 52 of 350


    4.2.9.           REVIEW AND APPROVAL TO PROCEED
    The 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.
    4.3.     ROLES AND RESPONSIBILITIES
    Each 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.
    4.4.     DELIVERABLES, RESPONSIBILITIES, AND ACTIONS
    The following deliverables shall be initiated during the System Concept Development Phase:

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                                 QPM #
                                                                                                  1
              Quality Management System                                 AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07           Page 53 of 350


    4.4.1.         SYSTEM BOUNDARY DOCUMENT
    The 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.
    4.4.2.         COST-BENEFIT ANALYSIS
    Provides 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.
    4.4.3.         FEASIBILITY STUDY
    Provides an overview of a business requirement or opportunity and determines if feasible
    solutions exist before full life-cycle resources are committed.
    4.4.4.         PROJECT RISK MANAGEMENT PLAN
    Identifies project risks and specifies the plans to reduce or mitigate the risks.
    4.5.     ISSUES FOR CONSIDERATION
    After 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.
    4.5.1.         PROJECT CONTINUATION DECISIONS
    The 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.
    4.5.2.         PROJECT APPROACH DECISIONS
    Each 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.


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                 1
             Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 54 of 350

    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.
    4.5.3.         ADP POSITION SENSITIVITY ANALYSIS
    Automated 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.
    4.5.4.         IDENTIFICATION OF SENSITIVE SYSTEMS
    Public 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.

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 55 of 350

    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.
    4.5.5.         ENTERPRISE ARCHITECTURE IN SYSTEM CONCEPT DEVELOPMENT
    Legislation (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.


    4.6.     REVIEW ACTIVITY
    The 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07           Page 56 of 350


    5        PHASE 2: PLANNING PHASE

    5.1.     OBJECTIVE
    Many 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.
    5.2.     TASKS AND ACTIVITIES
    The following tasks are performed as part of the Planning Phase. The results of these activities
    are captured in various project plans and solicitation documents.
    5.2.1.           REFINE ACQUISITION STRATEGY IN SBD
    During 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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                        AVS                                                 QPM #
                                                                                                    1
             Quality Management System                                 AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07            Page 57 of 350

    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).
    5.2.2.         ANALYZE PROJECT SCHEDULE
    Analyze and refine the project schedule, taking into account acquisition risk and resource
    availability. Develop a detailed schedule for the Requirements Analysis Phase.
    5.2.3.         CREATE INTERNAL PROCESSES
    Create, 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).
    5.2.4.         STAFF PROJECT OFFICE
    Further 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.
    5.2.5.         ESTABLISH AGREEMENTS WITH STAKEHOLDERS
    Establish 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).
    5.2.6.         PLAN THE PROJECT MANAGEMENT PLAN
    Plan, 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.
    5.2.7.         PLAN THE SYSTEMS ENGINEERING MANAGEMENT PLAN
    Plan, articulate, and gain approval of the strategy to execute the technical management aspects
    of the project (SEMP). Develop a detailed system work breakdown structure.
    5.2.8.         REVIEW FEASIBILITY OF SYSTEM ALTERNATIVES
    Review and validate the feasibility of the system alternatives developed during the previous
    phase (CBA, Feasibility Study). Confirm the continued validity of the need (SBD).
    5.2.9.         STUDY AND ANALYZE SECURITY IMPLICATIONS
    Study and analyze the security implications of the technical alternatives and ensure the
    alternatives address all aspects or constraints imposed by security requirements




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 58 of 350


    5.2.10.        DRAFT PRELIMINARY SECURITY PLAN
    The 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.
    5.2.11.        PRELIMINARY RISK ASSESSMENT
    The 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.
    5.2.12.        PLAN THE SOLICITATION, SELECTION AND AWARD
    During 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                               QPM #
                                                                                                   1
              Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 59 of 350


    5.2.13.        DEVELOP THE CONOPS
    Based 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.
    5.3.     ROLES AND RESPONSIBILITIES
    Project 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.
    5.4.     DELIVERABLES, RESPONSIBILITIES, AND ACTIONS
    5.4.1.         PROJECT MANAGEMENT PLAN
    This 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.


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                        AVS                                                  QPM #
                                                                                                     1
             Quality Management System                                  AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07            Page 60 of 350

    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 23, Project Management Plan.
    5.4.2.         SYSTEMS ENGINEERING MANAGEMENT PLAN
    The 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 25, Systems Engineering Management Plan.
    5.4.3.         CONCEPT OF OPERATIONS
    The 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 21, Concept of Operations.
    5.4.4.         CONFIGURATION MANAGEMENT PLAN
    The 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 19,
    Configuration Management Plan).
    5.4.5.         ACQUISITION PLAN
    This 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 18, Acquisition Plan, detailing the
    types of information that should be included in the Acquisition Plan.
    5.4.6.         SYSTEM SECURITY PLAN
    A 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.
    5.4.7.         PRELIMINARY RISK ASSESSMENT
    The 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.
    5.4.8.         VALIDATION AND VERIFICATION PLAN
    The 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 24, Verification and

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                            AVS                                              QPM #
                                                                                                    1
                 Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07            Page 61 of 350

    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.
    5.5.     ISSUES FOR CONSIDERATION
    5.5.1.           AUDIT TRAILS
    Audit 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.
    5.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.
    5.5.3.           ENTERPRISE ARCHITECTURE IN PLANNING
    Enterprise 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.


    5.6.     REVIEW ACTIVITY
    Upon 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.




                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                  Revision
                            AVS                                               QPM #
                                                                                                     1
                 Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                    Date: 2/5/07            Page 62 of 350


    6        PHASE 3: REQUIREMENTS ANALYSIS PHASE

    6.1.     OBJECTIVE
    The 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.
    6.2.     TASKS AND ACTIVITIES
    The 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 13, Alternative
    SDLC Work Patterns.
    6.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.
    6.2.2.           UPDATE RISK ASSESSMENT
    Update 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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07            Page 63 of 350


                  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.
    6.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 26, Functional Requirements Document.
    6.2.3.1.         Incorporate Information Security Requirements
    AVS information security requirements have been documented, and are summarized in Section
    51 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.
    6.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.


    6.2.4.           DEVELOP TEST CRITERIA AND PLANS
    Establish the test criteria and begin test planning. Include all areas where testing will take place
    and who is responsible for the testing.
    6.2.5.           DEVELOP THE TEST AND EVALUATION MASTER PLAN
    Describe 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.




                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                              QPM #
                                                                                                   1
              Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 64 of 350


    6.2.6.         DEVELOP AN INTERFACE CONTROL DOCUMENT
    The 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 28,
    Interface Control Document)
    6.2.7.         PREPARE FOIA/PA DOCUMENTS
    If 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.
    6.2.8.         CONDUCT REVIEWS
    The 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.
    6.2.9.         REVISE PREVIOUS DOCUMENTS
    The 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.
    6.3.     ROLES AND RESPONSIBILITIES
    Project 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.
    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 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.
    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.
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                 QPM #
                                                                                                    1
              Quality Management System                                 AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07           Page 65 of 350

    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.
    6.4.     DELIVERABLES, RESPONSIBILITIES, AND ACTIONS
    6.4.1.          FUNCTIONAL REQUIREMENTS DOCUMENT
    Serves 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.
    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.
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07          Page 66 of 350

    Consideration must also be given to persons with disabilities as required by the Rehabilitation
    Act, 20 U.S.C., Sec 794d (West Supp. 1999).
    6.4.2.           TEST AND EVALUATION MASTER PLAN
    Ensures 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
    6.4.3.           INTERFACE CONTROL DOCUMENT
    The 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 28, Interface Control Document, to see how multiple interfaces among multiple systems
    can be handled.
    6.4.4.           PRIVACY ACT REQUIREMENTS
    For 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
    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.

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                         AVS                                              QPM #
                                                                                                1
              Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 67 of 350

    The System of Records Notice shall be a required deliverable for the Requirements Analysis
    Phase of system development.
    6.4.5.         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. 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.
    6.5.     ISSUES FOR CONSIDERATION
    In 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).
    6.5.1.         ENTERPRISE ARCHITECTURE IN REQUIREMENTS ANALYSIS
    By 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)
    should be coordinated with the AVS Enterprise Architect and the final documentation coordinate
    to ensure accurate reporting in the architecture.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                        AVS                                              QPM #
                                                                                                1
             Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                               Date: 2/5/07           Page 68 of 350


    6.6.   REVIEW ACTIVITY
    Upon 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                         AVS                                              QPM #
                                                                                                1
              Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 69 of 350


    7        PHASE 4: DESIGN PHASE

    7.1.     OBJECTIVE
    The 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.
    7.2.     TASKS AND ACTIVITIES
    The 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 13, Alternative SDLC Work Patterns.
    7.2.1.         ESTABLISH THE APPLICATION ENVIRONMENT
    Identify/specify the target environment, the development environment and the design
    environment.
    7.2.2.         DESIGN THE APPLICATION
    In 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.
    7.2.3.         SELECT INFORMATION SECURITY CONTROLS
    Based on the results of the system categorization (see Section 5.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.



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                              QPM #
                                                                                                 1
              Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07            Page 70 of 350


    7.2.4.         DEVELOP CONTINGENCY PLAN
    Depending 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.
    7.2.5.         DEVELOP SYSTEM DESIGN DOCUMENT
    The 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 32, System Design Document).
    7.2.6.         DEVELOP MAINTENANCE MANUAL
    Develop the maintenance manual to ensure continued operation of the system once it is
    completed. This is a deliverable in the Design Phase. (See Section 34, Maintenance Manual)
    7.2.7.         DEVELOP OPERATIONS MANUAL
    Develop 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 35, Operations Manual and Section 36, System Administration Manual)
    7.2.8.         CONDUCT PRELIMINARY DESIGN REVIEW
    This 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.
    7.2.9.         DESIGN BUSINESS PROCESSES
    The business organization, roles and procedures for designing this system/application need to
    be articulated.
    7.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 37, Training Plan,
    and Section 38, User Manual)
    7.2.11.        DESIGN CONVERSION/MIGRATION/TRANSITION STRATEGIES
    If 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 31, Conversion Plan, Section 33,
    Implementation Plan, and Section 30, Contingency Plan)
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                              QPM #
                                                                                                   1
              Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 71 of 350


    7.2.12.        REVISE PREVIOUS DOCUMENTATION
    Documents 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.
    7.2.13.        DEVELOP SECURITY OPERATING PROCEDURES
    Develop procedures on how security will be handled throughout the Design Phase and who will
    be responsible for carrying out these procedures.
    7.2.14.        CONDUCT FINAL DESIGN REVIEW
    The 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.
    7.3.   ROLES AND RESPONSIBILITIES
    Project 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                QPM #
                                                                                                   1
              Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07            Page 72 of 350


    7.4.     DELIVERABLES, RESPONSIBILITIES, AND ACTIONS
    The 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.
    7.4.1.         DESIGN DOCUMENT
    The 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.
    7.4.2.         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.
    7.4.3.         USER MANUAL
    The 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.
    7.4.4.         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. 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.



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                               QPM #
                                                                                                 1
              Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 73 of 350


    7.4.5.         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 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.
    7.4.6.         INFORMATION SYSTEM SECURITY PLAN
    The 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.
    7.4.7.         CONTINGENCY PLAN
    The 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.
    7.4.8.         SYSTEM TEST AND EVALUATION PLAN
    This 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.
    7.4.9.         IMPLEMENTATION PLAN
    The 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.
    7.4.10.        OPERATIONS OR SYSTEMS ADMINISTRATION MANUAL
    For 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


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                              QPM #
                                                                                                    1
                 Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07           Page 74 of 350

    Administration Manual serves the purpose of an Operations Manual in distributed (client/server)
    applications.
    7.5.     ISSUES FOR CONSIDERATION
    7.5.1.           PROJECT DECISION ISSUES
    The 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.
    7.5.2.           SECURITY ISSUES
    The 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.
                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07          Page 75 of 350

    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.
    7.5.3.           ENTERPRISE ARCHITECTURE IN DESIGN
    The 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.
    7.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 7.4.1, Design Document).
    7.6.1.           REQUIREMENTS REVIEWS
    System/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.
    7.6.2.           DESIGN REVIEWS
    A 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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                               QPM #
                                                                                                   1
               Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07           Page 76 of 350


                  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.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                               QPM #
                                                                                                 1
              Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 77 of 350


    8        PHASE 5: DEVELOPMENT PHASE

    8.1.     OBJECTIVE
    The 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.
    8.2.     TASKS AND ACTIVITIES
    8.2.1.         PROCESS IMPLEMENTATION
    This 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.
    8.2.2.         SYSTEM REQUIREMENTS ANALYSIS
    Analyze 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
                         testability
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                            AVS                                                  QPM #
                                                                                                    1
                 Quality Management System                                  AQS 200-001-WI

Title: System Development Lifecycle                                       Date: 2/5/07       Page 78 of 350


                            feasibility of system architectural design
                            feasibility of operation and maintenance
                            degree of security assurance required
    8.2.3.           SYSTEM ARCHITECTURAL DESIGN
    Establish 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
    8.2.4.           SOFTWARE REQUIREMENTS ANALYSIS
    Establish 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
                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07          Page 79 of 350

    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).
    8.2.5.           SOFTWARE ARCHITECTURAL DESIGN
    Transform 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
    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).
    8.2.6.           SOFTWARE DETAILED DESIGN
    Develop 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.


                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07          Page 80 of 350

    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
    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).
    8.2.7.           SOFTWARE CODING AND TESTING
    Develop 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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                               QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07          Page 81 of 350


                    appropriateness of coding methods and standards used
                    feasibility of software integration and testing
                    feasibility of operation and maintenance
    8.2.8.           SOFTWARE INTEGRATION
    Develop 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.
    Update the user documentation as necessary.
    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
    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).
    8.2.9.           SOFTWARE QUALIFICATION TESTING
    Conduct qualification testing in accordance with the qualification requirements for the software
    item. Ensure that the implementation of each software requirement is tested for compliance.
    Update the user documentation as necessary.
    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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                               QPM #
                                                                                                   1
               Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07            Page 82 of 350


                  feasibility of system integration and testing, if conducted
                  feasibility of operation and maintenance
    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.
    8.2.10.        SYSTEM INTEGRATION
    Integrate 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


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                          AVS                                              QPM #
                                                                                                    1
               Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 83 of 350


    8.2.11.        SYSTEM QUALIFICATION TESTING
    Conduct system qualification testing in accordance with the qualification requirements specified
    for the system. Ensure that the implementation of each system requirement is tested for
    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.
    8.2.12.        SOFTWARE INSTALLATION
    Develop 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.
    8.2.13.        SOFTWARE ACCEPTANCE SUPPORT
    Support 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.
    8.3.   ROLES AND RESPONSIBILITIES
    Project 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.


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                QPM #
                                                                                                   1
              Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 84 of 350

    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.
    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.
    8.4.     DELIVERABLES, RESPONSIBILITIES AND ACTIONS
    The 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:
    8.4.1.         SOFTWARE DEVELOPMENT DOCUMENT
    Contains 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
    8.4.2.         SYSTEM (APPLICATION) SOFTWARE
    Used 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.
    8.4.3.         TEST FILES/DATA
    Used for system testing. Provide the actual test data and files used.
    8.4.4.         INTEGRATION DOCUMENT
    This will explain how the software components, hardware components, or both are combined
    and the interaction between them.
    8.4.5.         TEST ANALYSIS REPORT
    This is the formal documentation of the software testing as defined in the Test Report.
    8.4.6.         SYSTEM SECURITY TEST AND EVALUATION REPORT
    Results of security testing that were carried out during this phase should be documented
    separately.
    8.4.7.         PERIODIC PROGRESS REPORTS
    Progress 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
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                            AVS                                             QPM #
                                                                                                   1
                 Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07          Page 85 of 350

    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.
    8.5.     ISSUES FOR CONSIDERATION
    There are three phase prerequisites that should be completed before beginning this phase.
                    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.
    8.5.1.           ENTERPRISE ARCHITECTURE IN DEVELOPMENT
    By 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.


    8.6.     REVIEW ACTIVITY
    Upon 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.




                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                  Revision
                         AVS                                                 QPM #
                                                                                                     1
              Quality Management System                                 AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07             Page 86 of 350


    9        PHASE 6: INTEGRATION AND TEST PHASE

    9.1.     OBJECTIVE
    The 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.
    9.2.     TASKS AND ACTIVITIES
    The 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.
    9.2.1.         START TEST PHASE
    The test and evaluation team is responsible for establishing the test team and creating the test
    files/data.
    9.2.2.         CONDUCT SUBSYSTEM/SYSTEM TESTING
    The 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.
    9.2.3.         CONDUCT SECURITY TESTING
    The 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
    development phase for rework, and passed components will be migrated ahead for acceptance
    testing.
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                         AVS                                              QPM #
                                                                                                 1
              Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07            Page 87 of 350


    9.2.4.         CONDUCT ACCEPTANCE TESTING
    The 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.
    9.2.5.         REVISE PREVIOUS PHASE DOCUMENTATION
    During 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.
    9.3.     ROLES AND RESPONSIBILITIES
    Project 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.
    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 Certification and Accreditation documentation and
    for coordinating review by others as appropriate.
    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 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.
    9.4.     DELIVERABLES, RESPONSIBILITIES, AND ACTIONS
    The following deliverables shall be initiated during the Integration and Test Phase:



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                         AVS                                                 QPM #
                                                                                                    1
              Quality Management System                                 AQS 200-001-WI

Title: System Development Lifecycle                                   Date: 2/5/07            Page 88 of 350


    9.4.1.         TEST ANALYSIS APPROVAL DETERMINATION
    Attached 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
    9.4.2.         TEST PROBLEM REPORTS
    Document problems encountered during testing; the form is attached to the test analysis reports
    9.4.3.         IT SYSTEMS SECURITY CERTIFICATION & ACCREDITATION
    The 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.
    9.5.     ISSUES FOR CONSIDERATION
    9.5.1.         SECURITY
    Security 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.
    9.5.2.         ENTERPRISE ARCHITECTURE IN INTEGRATION & TESTING
    During 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                        AVS                                                QPM #
                                                                                                  1
             Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07            Page 89 of 350


    9.6.   REVIEW ACTIVITY
    Upon 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07            Page 90 of 350


    10     PHASE 7: IMPLEMENTATION PHASE

    10.1. OBJECTIVE
    In 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.
    10.2. TASKS AND ACTIVITIES
    Tasks and activities in the implementation phase are associated with certain deliverables
    described in section 10.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 13, Alternative SDLC Work Patterns. A description of these tasks and activities
    is provided below.
    10.2.1.        NOTIFICATION OF IMPLEMENTATION
    The 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.
    10.2.2.        EXECUTION OF TRAINING PLAN
    It 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.


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07            Page 91 of 350


    10.2.3.        DATA ENTRY OR CONVERSION
    With 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.
    10.2.4.        INSTALL SYSTEM
    To ensure that the system is fully operational, install the system in a production environment.
    10.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.
    10.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.
    10.2.7.        COMPLETION OF SECURITY CERTIFICATION AND ACCREDITATION
    The 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.



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                          AVS                                             QPM #
                                                                                                   1
               Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 92 of 350


    10.2.8.        REPORT SYSTEM AS OPERATIONAL IN THE ENTERPRISE ARCHITECTURE
    The 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.
    10.2.9.        POST-IMPLEMENTATION EVALUATION
    After 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.
    10.2.10.       REVIEW PREVIOUS DOCUMENTATION
    During 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.
    10.3. ROLES AND RESPONSIBILITIES
    Project 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.
    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 overseeing delivery of the final C&A documentation.
    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 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.
    10.4. DELIVERABLES, RESPONSIBILITIES, AND ACTIONS
    The deliverables described below are initiated during the Implementation Phase.



                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                         AVS                                              QPM #
                                                                                                1
              Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 93 of 350


    10.4.1.        DELIVERED SYSTEM
    After 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.
    10.4.2.        SCAP BINDER
    The final SCAP Binder (for delivery to AIS) should include the signature page, Risk
    Assessment, Security Plan, Contingency Plan, and System Test and Evaluation Results.
    10.4.3.        CHANGE IMPLEMENTATION NOTICE
    A formal request and approval document for changes made during the Implementation Phase.
    10.4.4.        VERSION DESCRIPTION DOCUMENT
    The 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.
    10.4.5.        POST-IMPLEMENTATION REVIEW REPORT
    This 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.
    10.5. ISSUES FOR CONSIDERATION


    10.5.1.        SECURITY
    Two 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.
    10.5.2.        ENTERPRISE ARCHITECTURE DURING IMPLEMENTATION
    When 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.


    10.6. REVIEW ACTIVITY
    A 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

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                  1
             Quality Management System                                AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 94 of 350

    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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                          AVS                                             QPM #
                                                                                                 1
               Quality Management System                             AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 95 of 350


    11     PHASE 8: OPERATIONS AND MAINTENANCE PHASE

    11.1. OBJECTIVE
    More 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.
    11.2. TASKS AND ACTIVITIES
    11.2.1.        SYSTEMS OPERATIONS
    Operations 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;
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07            Page 96 of 350


                  Ensure that security patches are monitored and applied regularly;
                  Monitor the performance statistics, report the results and escalate problems
                   when they occur.
    11.2.2.        DATA / SOFTWARE ADMINISTRATION
    Data / 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.
    11.2.3.        PROBLEM AND MODIFICATION PROCESS
    One 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 48) 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 44) 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.



                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

Title: System Development Lifecycle                                 Date: 2/5/07           Page 97 of 350


    11.2.4.        SYSTEM / SOFTWARE MAINTENANCE
    Daily 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.
    11.2.5.        REVIEW PREVIOUS DOCUMENTATION
    Review 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.
    11.3. ROLES AND RESPONSIBILITIES
    This 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


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                        AVS                                                 QPM #
                                                                                                   1
             Quality Management System                                 AQS 200-001-WI

Title: System Development Lifecycle                                  Date: 2/5/07            Page 98 of 350

    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.

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                             Revision
                         AVS                                              QPM #
                                                                                                1
              Quality Management System                              AQS 200-001-WI

Title: System Development Lifecycle                                Date: 2/5/07           Page 99 of 350

    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.
    11.4. DELIVERABLES, RESPONSIBILITIES AND ACTION
    11.4.1.        PERIODIC SYSTEM REVIEW REPORT
    Periodic 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.
    11.4.2.        USER SATISFACTION REVIEW
    When, 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.
    11.5. ISSUES FOR CONSIDERATION
    11.5.1.        DOCUMENTATION
    It 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.
    11.5.2.        ENTERPRISE ARCHITECTURE DURING OPERATIONS & MAINTENANCE
    Generally, 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.


    11.5.3.        CHANGES TO THE SYSTEM
    Boundary Documents should be reviewed and updated as needed, other documents as needed
    should be updated and on-going user training should be addressed.
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                   1
               Quality Management System                               AQS 200-001-WI

                                                                                              Page 100 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    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.
    11.5.4.        DISTINGUISHING NEW DEVELOPMENT FROM MAINTENANCE
    Changes 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
    11.6. REVIEW ACTIVITY
    Review 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.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                               QPM #
                                                                                                   1
              Quality Management System                               AQS 200-001-WI

                                                                                             Page 101 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                   350



    12     PHASE 9: DISPOSITION PHASE

    12.1. OBJECTIVE
    The 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 49) 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.
    12.2. TASKS AND ACTIVITIES
    The 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.
    12.2.1.        PREPARE DISPOSITION PLAN
    The 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.
    12.2.2.        ARCHIVE OR TRANSFER DATA
    The data from the old system will have to be implemented into the new system or if it is
    obsolete, archived.
    12.2.3.        ARCHIVE OR TRANSFER SOFTWARE COMPONENTS
    Similar 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.
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

                                                                                             Page 102 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350


    12.2.4.        ARCHIVE LIFE CYCLE DELIVERABLES
    A 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.
    12.2.5.        END THE SYSTEM IN AN ORDERLY MANNER
    Follow the plan in the Disposition Plan for the orderly breakdown of the system, its components
    and the data within.
    12.2.6.        DISPOSE OF EQUIPMENT
    If 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.
    12.2.7.        PREPARE POST-TERMINATION REVIEW REPORT
    This review will be performed at the end of the Disposition Phase and again within 6 months
    after disposition of the system.
    12.3. ROLES AND RESPONSIBILITIES
    Manager 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
    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.

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                                AQS 200-001-WI

                                                                                             Page 103 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350


    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.
    12.4. DELIVEABLES, RESPONSIBILITIES AND ACTION
    The following deliverables are initiated and finalized during the Disposition Phase
    12.4.1.        DISPOSITION PLAN
    The 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
    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

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                QPM #
                                                                                                   1
              Quality Management System                                AQS 200-001-WI

                                                                                              Page 104 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    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.
    12.4.2.        POST-TERMINATION REVIEW REPORT
    The Post-Termination Review Report is a report at the end of the process that details the
    findings of the Disposition Phase review.
    12.4.3.        ARCHIVED SYSTEM
    The packaged set of data and documentation containing the archived application is retained.
    12.5.     ISSUES FOR CONSIDERATION
    Update 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.
    12.5.1.        ENTERPRISE ARCHITECTURE DURING DISPOSITION
    The 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.


    12.6. REVIEW ACTIVITY
    The 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.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

                                                                                              Page 105 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350



    13     ALTERNATIVE SDLC WORK PATTERNS

    13.1. OBJECTIVE
    An 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.
    13.1.1.        STANDARD SDLC METHODOLOGY (FULL SEQUENTIAL WORK PATTERN)
    The standard SDLC methodology, as represented in Section 4, Phase 1: System Concept
    Development Phase through Section 12, 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-2: Planning Documents, in Section 3, 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 4 through 12.
    13.2. ALTERNATIVE WORK PATTERNS
    Alternative 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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                          AVS                                                 QPM #
                                                                                                     1
               Quality Management System                                  AQS 200-001-WI

                                                                                               Page 106 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                   350


                  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.
    13.3. ALTERNATIVE WORK PATTERN SELECTION
    During 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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                                 QPM #
                                                                                                  1
               Quality Management System                               AQS 200-001-WI

                                                                                              Page 107 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                 350


                  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;


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                          AVS                                              QPM #
                                                                                                   1
               Quality Management System                              AQS 200-001-WI

                                                                                               Page 108 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


                   The project affects many organizations or functional areas within AVS, thus
                    adding a level of difficulty regarding the definition of requirements.
                   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-1: Alternative Work Pattern Selection, to select the work pattern appropriate for
    your project.
    FIGURE 13-1: ALTERNATIVE WORK PATTERN SELECTION

                        Selection Criteria                        Work Pattern
               A. Type of Development = any
               B. Cost = Class 4
                                                     Reduced Effort (small application)
               C. Mission Criticality = all
                                                     Work Pattern
               D. Risk = D2 to D1
               E. Complexity = E2 or E1
               A. Type of Development = 1, 2, 3
               B. Cost = Class 3 or 4
               C. Mission Criticality = all          RAD Work Pattern
               D. Risk = D2 to D1
               E. Complexity = E2 or E1
               A. Type of Development = 1
               B. Cost = Class 2 and 3
               C. Mission Criticality = C2 to C3     Pilot Development Work Pattern
               D. Risk = D3
               E. Complexity = high
               A. Type of Development = 1
               B. Cost = Class 1 and 2
               C. Mission Criticality = C3 or C2     MED Work Pattern
               D. Risk = D3
               E. Complexity = E3
               A. Type of Development = 1
               B. Cost = Class 1 and 2
               C. Mission Criticality = C3 to C2     Full Sequential Work Pattern
               D. Risk = D3
               E. Complexity = E3 to E2

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                              QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

                                                                                              Page 109 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                  350


                      Selection Criteria                          Work Pattern
              A. Type of Development = 5
              B. Cost = Class 5
              C. Mission Criticality = Any           O&M Small Scale Enhancement
              D. Risk = Any
              E. Complexity = Any
              A. Type of Development = 6
              B. Cost = Class 2 to 4
              C. Mission Criticality = Any           O&M Project
              D. Risk = Any
              E. Complexity = Any
              A. Type of Development = 4
              B. Cost = Class 3 or 4
              C. Mission Criticality = Any           COTS Acquisition
              D. Risk = Any
              E. Complexity = Any


    13.4. WORK PATTERN DESCRIPTIONS AND EXHIBITS
    The 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.
    13.4.1.        REDUCED EFFORT WORK PATTERN
    A 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-2:
    Reduced Effort Work Pattern. Figure 13-3: 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.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                        AVS                                                    QPM #
                                                                                                        1
             Quality Management System                                  AQS 200-001-WI

                                                                                                Page 110 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                     350


    FIGURE 13-2: REDUCED EFFORT WORK PATTERN




    FIGURE 13-3: REDUCED EFFORT WORK PATTERN SUMMARY
                                                        Deliverables (Work
              Phase                   Tasks                                         Formal Reviews
                                                             Products)
       System Concept         Define/document          Cost-Benefit Analysis    Cost-Benefit Analysis
       Development              business need          Risk Management          Risk Management
                              Develop a                  Plan                     Plan
                                recommendation         System Boundary          Feasibility Study
                              Present findings to        Document               System Boundary
                                executive              Feasibility Study          Document
                                management
                                                                                Phase-End
                              Conduct ADP position
                                sensitivity analysis
       Planning and           Review security          Acquisition Plan         Acquisition Plan
       Requirements             requirements           CM Plan                  CM Plan
       Analysis               Plan CM                  Project Management       Project Management
                              Analyze and                Plan                     Plan
                                document               Concept of               Concept of
                                requirements             Operations               Operations
                              Develop test criteria    FRD                      Functional
                                and plans                                         Requirements
                                                       QA Plan
                              Establish QA                                      QA Plan
                                                       Test & Evaluation
                                mechanisms
                                                         Master Plan            Test & Evaluation
                              Establish project and
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                        AVS                                                    QPM #
                                                                                                       1
             Quality Management System                                  AQS 200-001-WI

                                                                                                Page 111 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                      350


                                                        Deliverables (Work
              Phase                   Tasks                                          Formal Reviews
                                                             Products)
                                 system security        System Security Plan     Master Plan
                                                        Privacy Act Notice      System Security Plan
                                                        ICD                     System Interfaces
                                                        Systems Engineering     V&V Plan
                                                          Management Plan       Systems Engineering
                                                        V&V Plan                 Management Plan
                                                        Records Disposition     Phase-End
                                                          Schedule
       Design and              Design the application   System Design           Final System Design
       Development             Design business            Document              Implementation Plan
                                 processes              Implementation Plan     Security Risk
                               Design                   Software                  Assessment
                                 conversion/migratio      Development           Contingency Plan
                                 n/transition             Document
                                                                                Conversion Plan
                                 strategies             System Software
                                                                                Maintenance Manual
                               Continue procurement     Test files/data
                                 activities                                     Training Plan
                                                        Contingency Plan
                               Continue CM and                                  User Manual
                                                        Operations Manual
                                 change control                                 Integration Document
                                                        Conversion Plan
                               Develop security                                 Software peer reviews
                                 operating              Security Risk
                                                                                Test Readiness
                                 procedures               Assessment
                                                                                Phase-End
                               Develop the              Maintenance Manual
                                 application            Training Plan
                               Develop business         User Manual
                                 processes              Integration Document
                               Institute internal       Test Analysis Report
                                 management
                                 controls
       Integration &Test and   Conduct subsystem        Test Problem Reports    Version Description
       Implementation            integration testing    Test Analysis            Document
                               Conduct system             Approval              Post-implementation
                                 testing                  Determination          Review
                               Conduct user             IT Systems Security     Phase-End
                                 acceptance testing       Certification &
                               Conduct test analysis      Accreditation
                                 review                 Delivered system
                               Computer user and        Change
                                 operator training        Implementation
                               Install system in          Notice
                                 production             Version Description
                                 environment              Document (initial

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                   Revision
                         AVS                                                  QPM #
                                                                                                      1
              Quality Management System                                   AQS 200-001-WI

                                                                                                  Page 112 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                     350


                                                       Deliverables (Work
              Phase                   Tasks                                         Formal Reviews
                                                            Products)
                              Convert data to          release)
                               production             Post-implementation
                               environment             Review Report
                              Confirm that the
                               system is ready for
                               operation
                              Continue
                               configuration status
                               accounting and
                               change control
                              Certify system
                               security and
                               readiness features
                              Complete acquisitions
                              Perform operation
                               reviews
                              Obtain formal
                               acceptance of the
                               installed system
                               from the user
       Operations &           All in Chapter 11       Periodic System          Periodic System
       Maintenance            Note: System begins      Review Report            Review
                                O&M Project Work      User Satisfaction        User Satisfaction
                                Pattern                Review                   Review
                                                      Note: See O&M            Note: See O&M
                                                       Project                  Project
       Disposition            All in Chapter 12       Disposition Plan         Post-disposition
                                                      Post-termination
                                                        Review Report

    13.4.2.          RAPID APPLICATION DEVELOPMENT WORK PATTERN
    In 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
    repeated - always involving the user. Typically, three cycle iterations will result in a completely

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                  1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 113 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                  350


    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-4: RAD Work Pattern. Figure
    13-5: RAD Work Pattern Summary, shows, by phase, the tasks, the deliverables required, and
    the types of reviews required.
    FIGURE 13-4: RAD WORK PATTERN




    FIGURE 13-5: RAD WORK PATTERN SUMMARY

                                                      Deliverables (Work
                Phase                 Tasks                                      Formal Reviews
                                                           Products)




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                   Revision
                        AVS                                                  QPM #
                                                                                                       1
             Quality Management System                                   AQS 200-001-WI

                                                                                                  Page 114 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                     350


                                                                               Cost-Benefit Analysis
                                                     Cost-Benefit Analysis
                                                                               Feasibility Study
                                                     Feasibility Study
                                                                               Risk Management
         System Concept                              Risk Management
                               All in Chapter 4                                  Plan
         Development                                   Plan
                                                                               System Boundary
                                                     System Boundary            Document
                                                      Document
                                                                               Phase-End

                                                                               Acquisition Plan
                                                     Acquisition Plan
                                                                               CM Plan
                                                     CM Plan
                                                                               QA Plan
                                                     QA Plan
                                                                               Project Management
                                                     Project Management          Plan
                                                       Plan
         Planning              All in Chapter 5                                V&V Plan
                                                     V&V
                                                                               CONOPS
                                                     CONOPS
                                                                               System Security Plan
                                                     System Security Plan
                                                                               Systems Engineering
                                                     Systems Engineering        Management Plan
                                                      Management Plan
                                                                               Phase-End




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                       Revision
                        AVS                                                     QPM #
                                                                                                          1
             Quality Management System                                     AQS 200-001-WI

                                                                                                    Page 115 of
Title: System Development Lifecycle                                      Date: 2/5/07
                                                                                                         350


                               The following
                                combined phase
                                tasks are iterative:   FRD

                               Assess the current      System Design
                                                        Document (Based            Functional
                                situation
                                                        on Design                    Requirements
                               Analyze and              Prototype)                 Design (Based on
                                document
                                                       Interface Control            Design Prototype)
                                requirements
                                Establish the            Document                  System Interfaces
                                application            Test & Evaluation           Test & Evaluation
                                environment             Master Plan                 Master Plan
                               Design the              Security Risk               Security Risk
                                application             Assessment                  Assessment
                               -End of iterative       Implementation Plan         Implementation Plan
                                 tasks-
                                                       Privacy Act Notice          Design Phase-End
                               The following
         Requirements           combined phase         Records Disposition         Contingency Plan
         Analysis and Design    tasks are not           Schedule
                                                                                   Conversion Plan
                                iterative:             Contingency Plan
                                                                                   Maintenance Manual
                               Develop test criteria   Conversion Plan
                                                                                   Operations Manual or
                               Establish project and   Maintenance Manual           Systems
                                system security
                                                       Operations Manual or         Administration
                               Revise Planning          Systems                     Manual
                                Phase documents         Administration              (client/server)
                               Design business          Manual                     Training Plan
                                processes               (client/server)
                                                                                   User Manual
                               Design                  Training Plan
                                                                                   Note: Requirements
                                conversion/migratio    User Manual                  and Design reviews
                                n/ transition
                                                       Note: FRD and SDD            may be combined.
                                strategies
                                                        may be published
                               Develop security         as one deliverable
                                operating
                                procedures

                                                       Software
                                                        Development
                                                        Document                   Software peer
                                                                                    reviews
                                                       Integration Document
         Development           All in Chapter 8
                                                                                   Test Readiness
                                                       System software
                                                                                   Phase-end
                                                       Test files/data
                                                       Test Analysis Report


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                   Revision
                         AVS                                                 QPM #
                                                                                                      1
              Quality Management System                                  AQS 200-001-WI

                                                                                               Page 116 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                     350


                                                      Test Problem
                                                       Reports
                                                      Test Analysis
                                                       Approval
         Integration & Test    All in Chapter 9                                Phase-End
                                                       Determination
                                                      IT Systems Security
                                                        Certification &
                                                        Accreditation

                                                      Delivered system
                                                      Post-implementation
                                                       Review Report           Version Description
                                                                                Document
                                                      Change
         Implementation        All in Chapter 10       implementation          Post-implementation
                                                       Notice                   Review

                                                      Version Description      Phase-End
                                                       Document (initial
                                                       release)

                               All in Chapter 11      Periodic System          Periodic System
         Operations &                                  Review Report            Review
                               Note: System begins
          Maintenance           O&M Project Work      User Satisfaction        User Satisfaction
                                Pattern                Review                   Review

                                                      Disposition Plan
         Disposition           All in Chapter 12      Post-termination         Post-Disposition
                                                       Review Report

    13.4.3.         PILOT DEVELOPMENT WORK PATTERN
    In 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-6: Pilot
    Development Work Pattern. Figure 13-7: Pilot Development Work Pattern Summary, shows, by
    phase, the tasks, the deliverables required, and the types of reviews required.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                        AVS                                               QPM #
                                                                                                      1
             Quality Management System                               AQS 200-001-WI

                                                                                             Page 117 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


    FIGURE 13-6: PILOT DEVELOPMENT WORK PATTERN




    FIGURE 13-7: PILOT DEVELOPMENT WORK PATTERN SUMMARY

                                                        Deliverables (Work
         Phase                     Tasks                                            Formal Reviews
                                                             Products)

                                                                                  Cost-Benefit Analysis
                                                     Cost-Benefit Analysis        Feasibility Study
                                                     Feasibility Study            Risk Management
    System Concept
                      All in Chapter 4               Risk Management Plan           Plan
     Development
                                                     System Boundary              System Boundary
                                                      Document                     Document
                                                                                  Phase-End




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                   Revision
                          AVS                                                QPM #
                                                                                                        1
               Quality Management System                                AQS 200-001-WI

                                                                                                Page 118 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                     350


                                                         Deliverables (Work
         Phase                     Tasks                                               Formal Reviews
                                                              Products)

                                                                                     Acquisition Plan
                                                      Acquisition Plan               CM Plan
                                                      CM Plan                        QA Plan
                                                      QA Plan                        Project Management
                                                      Project Management Plan          Plan
    Planning          All in Chapter 5                CONOPS                         System Security Plan

                                                      System Security Plan           CONOPS

                                                      V&V Plan                       V&V Plan

                                                      Systems Engineering            Systems Engineering
                                                       Management Plan                Management plan
                                                                                     Phase-End

                                                      FRD
                      All in Chapter 6                                               Functional
                                                      Test & Evaluation Master         Requirements
                      Note: The Pilot Development      Plan
    Requirements       Work Pattern may also follow                                  Test & Evaluation
                       the Rapid Application          ICD                             Master Plan
     Analysis
                       Development Work Pattern for   Privacy Act Notice             System Interfaces
                       the Requirements Analysis
                       and Design Phases.             Records Disposition            Phase-End
                                                       Schedule

                                                                                     Design
                                                      Software Development           Implementation Plan
                                                       Document
                                                                                     Conversion Plan
                                                      Security Risk Assessment
                                                                                     Maintenance Manual
                      All in Chapter 7                Implementation Plan
                                                                                     Operations Manual or
                      Note: The Pilot Development     Conversion Plan                 Systems
                       Work Pattern may also follow   Maintenance Manual              Administration
    Design             the Rapid Application                                          Manual
                       Development Work Pattern for   Operations Manual or            (Client/server)
                       the Requirements Analysis       Systems Administration
                                                       Manual (Client/server)        Training Plan
                       and Design Phases.
                                                      Training Plan                  User Manual

                                                      User Manual                    Contingency Plan

                                                      Contingency Plan               Final System Design
                                                                                     (Phase-End)



                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                    Revision
                         AVS                                                    QPM #
                                                                                                           1
              Quality Management System                                    AQS 200-001-WI

                                                                                                   Page 119 of
Title: System Development Lifecycle                                    Date: 2/5/07
                                                                                                         350


                                                            Deliverables (Work
         Phase                        Tasks                                               Formal Reviews
                                                                 Products)

                                                         Software Development
                                                          Document
                                                                                        Software peer
                                                         Integration Document            reviews
    Development          All in Chapter 8
                                                         System software                Test Readiness
                                                         Test Analysis Report           Phase-End
                                                         Test files/data

                                                         Test Problem Reports
                                                         Test Analysis Approval
    Integration and                                       Determination                 Field Test and
                         All in Chapter 9
      Test                                                                                Evaluation
                                                         IT Systems Security
                                                           Certification &
                                                           Accreditation

                                                         Deferred until Field Test
                                                          and Evaluation proves
                                                          system concept, then
                         Deferred until Field Test and    Delivered system              Post-implementation
                          Evaluation proves system                                       Review
    Implementation                                       Change Implementation
                          concept, then all in Chapter
                                                          Notice                        Phase-End
                          10
                                                         Post-implementation
                                                          Review Report Version
                                                          Description Document

                                                         Deferred until Field Test
                                                                                        User Satisfaction
                         Deferred until Field Test and    and Evaluation proves
                                                                                         Review
    Operations &          Evaluation proves system        system concept, then
     Maintenance          concept, then all in Chapter    Periodic System               Periodic System
                          11                              Review Report                  Review (to evaluate
                                                                                         concept)
                                                         User Satisfaction Review

                                                         Disposition Plan
    Disposition          All in Chapter 12               Post-termination Review        Post-disposition
                                                          Report



    13.4.4.           MANAGED EVOLUTIONARY DEVELOPMENT WORK PATTERN
    The 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
    defined early in the development life cycle. The MED discipline supports iterative definition,
                               UNCONTROLLED COPY WHEN DOWNLOADED
                  Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                        AVS                                                  QPM #
                                                                                                    1
             Quality Management System                                  AQS 200-001-WI

                                                                                               Page 120 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


    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-8: MED Work Pattern. Figure 13-9: MED Work Pattern Summary,
    shows, by phase, the tasks, the deliverables required, and the types of reviews required.
    FIGURE 13-8: 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
    usage experience is obtained, lessons learned are fed back into each subsystem by improving
    each in subsequent versions of the system.

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                               QPM #
                                                                                                  1
             Quality Management System                               AQS 200-001-WI

                                                                                             Page 121 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                 350


    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-9: MED WORK PATTERN SUMMARY
                                                        Deliverables (Work
             Phase                    Tasks                                         Formal Reviews
                                                             Products)
                                                                                  Cost-Benefit Analysis
                                                       Cost-Benefit Analysis
                                                                                  Feasibility Study
                                                       Feasibility Study
                               All in Chapter 4                                   Risk Management
      System Concept                                   Risk Management
                               Determine System                                   Plan
      Development                                      Plan
                               Boundary                                           System Boundary
                                                       System Boundary            Document
                                                       Document
                                                                                  Phase-End




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                          AVS                                               QPM #
                                                                                                    1
               Quality Management System                               AQS 200-001-WI

                                                                                                Page 122 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


                                                           Deliverables (Work
               Phase                     Tasks                                        Formal Reviews
                                                                Products)
                                                                                    Acquisition Plan
                                                          Acquisition Plan
                                                                                    CM Plan
                                                          CM Plan
                                                                                    QA Plan
                                                          QA Plan
                                 All in Chapter 5 plus:                             Project Management
                                                          Project Management        Plan
                                 Divide system into       Plan
                                 independent                                        CONOPS
      Planning                                            CONOPS
                                 subsystems Plan                                    Systems Security
                                 incremental releases     Systems Security          Plan
                                 (builds)                 Plan
                                                                                    V&V Plan
                                                          V&V Plan
                                                                                    Systems Engineering
                                                          System Engineering        Management Plan
                                                          Management Plan
                                                                                    Phase-End
                                 All in Chapter 6
                                 Note: All Tasks,         FRD
                                 Deliverables, and                                  Functional
                                 Reviews from             Test & Evaluation         Requirements
                                 Requirements             Master Plan
      Requirements                                                                  Test & Evaluation
                                 Analysis Phase           ICD                       Master Plan
      Analysis
                                 through Operations &     Records Disposition       System Interfaces
                                 Maintenance Phase        Schedule
                                 are done for each                                  Phase-End
                                                          Privacy Act Notice
                                 build defined during
                                 the Planning Phase
                                                                                    Design
                                                          Systems Design
                                                                                    Implementation Plan
                                                          Document
                                                                                    Conversion Plan
                                                          Implementation Plan
                                                                                    Maintenance Manual
                                                          Conversion Plan
                                                                                    Operations Manual or
                                                          Maintenance Manual
                                                                                    Systems
                                                          Operations Manual or      Administration Manual
                                                          Systems                   (client/server)
      Design                     All in Chapter 7
                                                          Administration Manual
                                                                                    Training Plan
                                                          (client/server)
                                                                                    User Manual
                                                          Training Plan
                                                                                    Contingency Plan
                                                          User Manual
                                                                                    Security Risk
                                                          Contingency Plan
                                                                                    Assessment
                                                          Security Risk
                                                                                    Final System Design
                                                          Assessment
                                                                                    (Phase-End)




                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                               QPM #
                                                                                                      1
              Quality Management System                              AQS 200-001-WI

                                                                                               Page 123 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                  350


                                                         Deliverables (Work
              Phase                    Tasks                                         Formal Reviews
                                                              Products)
                                                       Software
                                                       Development
                                                       Document                    Software peer reviews
      Development              All in Chapter 8        Integration Document        Test Readiness
                                                       System software             Phase-End
                                                       Test Analysis Report
                                                       Test files/data
                                                       Test Problem Reports
                                                       and Test Analysis
                                                       approval
      Integration and Test     All in Chapter 9        Determination               Phase-End
                                                       IT Systems Security
                                                       Certification &
                                                       Accreditation
                                                       Version Description
                                                       Document (per build,
                                                       up to complete              Post-implementation
                                                       system)                     Review
      Implementation           All in Chapter 10       Change                      Version Description
                                                       Implementation Notice       Document
                                                       Post-implementation         Phase-End
                                                       Review Report
                                                       Delivered system
                               All in Chapter 11       Periodic System             Periodic System
      Operations &             Note: System begins     Review Report               Review
      Maintenance              O&M Project Work        User Satisfaction           User Satisfaction
                               Pattern                 Review                      Review
                                                       Disposition Plan
      Disposition              All in Chapter 12       Post-termination            Post-disposition
                                                       Review Report

    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.
    13.4.5.          O&M SMALL-SCALE ENHANCEMENT WORK PATTERN
    This 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.


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                        AVS                                                  QPM #
                                                                                                    1
             Quality Management System                                   AQS 200-001-WI

                                                                                               Page 124 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                   350


    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-10: O&M Enhancement Work Pattern Summary shows, by phase, the tasks,
    deliverables, and types of reviews required.
    FIGURE 13-10: O&M ENHANCEMENT WORK PATTERN SUMMARY
                                                                 Deliverables (Work
           Phase                        Tasks                                                Reviews
                                                                      Products)
                           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               Change Impact              IRM review of
                             module(s) in which to make          Assessment                 SCR
                             changes.
    Concept Development                                        Change Directive           Project
     and Planning Phase    Identify urgency and priority                                    Management
                                                               Project Management
                           Develop a work schedule and           Plan (Small-scale          Plan
                             estimate of resource                enhancement)             Phase-End
                             requirements.
                           Identify release and version
                             number in which the change
                             will be included.
                           Identify existing security and
                             privacy requirements for the
                             application needing revision.
                           Identify applicable                 Addendum to CONOPS         CONOPS
                             requirements; issue FRD           Addendum to FRD             Requirements
    Requirements             addendum.                         Addendum to ICD            System
     Analysis and
                           Design the required change.         Marked-up pages of          Interfaces
     Design Phases
                           Identify needed revisions to         baseline documents        Updated Design
                             baseline documents.                requiring changes          (Phase-End)




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                         AVS                                                 QPM #
                                                                                                      1
              Quality Management System                                 AQS 200-001-WI

                                                                                               Page 125 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                   350


                                                              Updated Software
                                                               Development
                                                               Document
                           Develop changes
                                                              Updated system software
                           Make changes to appropriate                                    Software peer
                                                              Updated test files/data
    Development and         documentation.                                                 reviews
     Integration & Test                                       Test Analysis Report with
                           Revise and unit test application                               Test Readiness
     Phases                                                    attached Test Problem
                            software.
                                                               Reports                    Phase-End
                           Conduct system and regression
                                                              Test Analysis Approval
                            testing for this change.
                                                               Determination
                                                              Updated Integration
                                                               Document
                           Complete Change
                            Implementation Notice             Modified software and
    Implementation                                             documentation
                           Deploy revised software and                                    Phase-End
      Phase                                                   Change Implementation
                            documentation
                                                               Notice
                           Conduct required training



    13.4.6.          O&M PROJECT WORK PATTERN
    This 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-11: O&M Project Work Pattern Summary, shows, by activity, the task, deliverables,
    and types of reviews required.
    FIGURE 13-11: O&M PROJECT WORK PATTERN SUMMARY
                                                                Deliverables (Work
          Phases                       Tasks                                                 Reviews
                                                                     Products)




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                        AVS                                                  QPM #
                                                                                                    1
             Quality Management System                                 AQS 200-001-WI

                                                                                               Page 126 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                    350


                                                               Deliverables (Work
          Phases                        Tasks                                               Reviews
                                                                    Products)
                          Evaluate SCR(s)
                          Obtain approval to maintain an
                            existing application.
                          Determine appropriate module(s)
                            in which to make changes.                                   Change Control
                                                              Change Impact
                          Identify urgency and priority.                                  Board review of
                                                                Assessment
    Concept                                                                               SCR
                          Develop a work schedule and         Change Directive
     Development and        estimate of resource                                        Project
     Planning Phase                                           Project Management          Management
                            requirements.
                                                                Plan (based on type       Plan
                          Identify release and version          of maintenance)
                            number in which the change will                             Phase-End
                            be included.
                          Identify existing security and
                            privacy requirements for the
                            application needing revision.
                                                              Addendum to               CONOPS
                          Identify applicable requirements;    CONOPS                    (enhancement
                            issue FRD addendum if SCR(s)       (Enhancement only)        only)
    Requirements            add or modify functional or       Addendum to FRD           Requirements
     Analysis and           performance requirements.          (Enhancement only)        (enhancement
     Design Phases        Design the required change.         Addendum to ICD            only)
                          Identify needed revisions to        Marked-up pages of        System Interfaces
                            baseline documents.                baseline documents       Updated Design
                                                               requiring changes         (Phase-End)
                                                              Updated Software
                                                               Development
                          Develop changes                      Document
                          Make changes to appropriate         Updated system
                                                                                        Software peer
    Development and        documentation.                      software
                                                                                         reviews
     Integration & Test   Revise and unit test application    Updated test files/data
                                                                                        Test Readiness
     Phases                software.                          Test Analysis Report
                                                                                        Phase-End
                          Conduct system and regression        with attached Test
                           testing for this change.            Problem Reports
                                                              Test Analysis Approval
                                                               Determination
                          Complete Change Implementation      Modified software and
                           Notice                              documentation
    Implementation
                          Deploy revised software and         Change                    Phase-End
      Phase
                           documentation                       Implementation
                          Conduct required training            Notice



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                    Revision
                         AVS                                                     QPM #
                                                                                                          1
              Quality Management System                                     AQS 200-001-WI

                                                                                                  Page 127 of
Title: System Development Lifecycle                                       Date: 2/5/07
                                                                                                      350


                                                                     Deliverables (Work
          Phases                           Tasks                                                Reviews
                                                                          Products)
    Conduct Adaptive                                               See O&M                 See O&M
      Maintenance           See O&M Enhancement work
                                                                    Enhancement work        Enhancement
                             pattern.
    (ongoing)                                                       pattern.                work pattern.
    Provide User Help       Respond to user requests for help.                             Periodic peer
      Desk Support                                                 None
                            Maintain log of trouble tickets.                                review
      (ongoing)

    13.4.7.           PROCUREMENT OF COTS PRODUCT
    This 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-12. 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-1: Alternative Work Pattern Selection,
    indicates when this pattern is to be used.
    FIGURE 13-12: COTS ACQUISITION WORK PATTERN SUMMARY
                                                                   Deliverables (Work
              Phase                        Tasks                                               Reviews
                                                                        Products)
                                                                 Feasibility Study
                                                                 Cost Benefit Analysis
                                                                 Risk Management Plan
                                                                                           CONOPS
                                                                 User Group Charter
                               Define business need                                        System Concept
    Concept Development                                          Project Management
                                                                                             Development and
     and Planning Phases       Charter User Group                  Plan
                                                                                           Planning Phase
                                                                 CM Plan
                                                                                             End
                                                                 QA Plan
                                                                 Acquisition Plan
                                                                 CONOPS
                               Identify functional               FRD
                                 requirements
                                                                 System Security Plan
                               Identify sensitivity of the
                                 system                          Security Operating
                                                                   Procedures (See Note)
                               Conduct security risk
                                 assessment                      Contingency Plan (See
    Requirements Analysis
                                                                   Note)                   Requirements
     Phase                     Develop plan for User
                                 Acceptance Testing              Security Risk
                                                                   Assessment
                               Determine Privacy Act
                                 implications                    User Acceptance Test
                                                                   Plan
                               Continue acquisition
                                 activities                      Privacy Act Notice



                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                         AVS                                                 QPM #
                                                                                                    1
              Quality Management System                                 AQS 200-001-WI

                                                                                              Page 128 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                   350


                                                               Deliverables (Work
            Phase                       Tasks                                             Reviews
                                                                    Products)
                             Perform Market Survey
                             Evaluate products
                             Initiate selection process
                             Define customization            Statement of Work
                               requirements
                                                             ICD
                             Prepare Statement of Work                               Statement of Work
    Acquisition Phase                                        User Manual
                             Obtain AIS approval                                     System Interfaces
     (replaces Design and                                    Training Plan
     Development)            Initiate purchase of selected                           Implementation
                                                             Conversion Plan
                               COTS                                                    Plan
                                                             Implementation Plan
                             Develop User manual
                                                             COTS Product
                             Prepare Training Plan
                             Develop Conversion Plan
                             Develop Implementation
                               Plan
                             Conduct Stress Test
                             Conduct Network Load Test
                             Conduct User Acceptance
                               Test
    Integration & Test       Conduct Security Test and       Test Plan
                                                                                     Test Plan
      Phase                    Evaluation                    Test Problem Report
                             Review test results
                             Initiate problem resolutions
                             Prepare User Acceptance
                               Certificate

                             Conduct training                Change Control Board
                                                               Charter
                             Convert data
    Implementation Phase                                     IT Systems Security     None
                             Implement software
                                                               Certification &
                             Charter Change Control            Accreditation (See
                               Board                           Note)
                             Monitor system
                             Identify problems
                             Conduct Change Control
                               Board Meetings
    Operations &
                             Notify vendor of application    None                    None
     Maintenance Phase
                               problem
                             Initiate formal acquisition
                               request for any system
                               customization requirement


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                               QPM #
                                                                                                 1
             Quality Management System                               AQS 200-001-WI

                                                                                             Page 129 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                350


                                                            Deliverables (Work
            Phase                       Tasks                                            Reviews
                                                                 Products)
                                                          Disposition Plan          Disposition Plan
    Disposition Phase        All in Chapter 12            Post-Termination Review   Post-termination
                                                            Report                    (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.
    13.5. ADDITIONAL WORK PATTERNS
    Project 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                  1
             Quality Management System                                AQS 200-001-WI

                                                                                             Page 130 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350



    14     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.
    14.1. FORMAT FOR SBD COVER MEMO
    FROM: 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.
    14.2. THE REQUIREMENTS DOCUMENT
    The Requirements Document (RD) establishes the operational framework and performance
    baseline for an automation program, and serves as an “agreement” with the customer on the

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 131 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


    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.
    14.3. TRACEABILITY
    The 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.
    14.4. APPROVAL
    A 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.
    14.5. USING THIS TEMPLATE
    This 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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 132 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


    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.
    14.6. AQS-200-CONTROLLED PARAMETERS
    Certain 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.
    14.7. CHANGE CONTROL
    As 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.
    14.8. COST
    The 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.
    14.9. SCHEDULE
    The 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.
    14.10. BENEFITS
    Benefit requirements at the beginning of Design Phase are the benefits defined in the
    CONOPS. Benefits must be measurable.


               Chapter/Section                                   Definition




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                        Revision
                          AVS                                                    QPM #
                                                                                                               1
               Quality Management System                                    AQS 200-001-WI

                                                                                                      Page 133 of
Title: System Development Lifecycle                                      Date: 2/5/07
                                                                                                           350


                 Chapter/Section                                       Definition
                                           Identify the Concept Paper addressed by this Requirements
                                           Document and summarize the mission need. Describe briefly
                                           the deficiency in capability or technological opportunity, and
       Ch.1      Background
                                           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
                                           Describe how the capability will be used after it is deployed,
           2.1      Operations             and how it will support and affect primary customers (e.g.,
                                           FAA engineers, FAA manufacturing inspectors, designees).
                                           Describe the intended life of the capability from
                                           implementation through decommissioning. Include
           2.2      Maintenance            requirements for preventive maintenance, planned
                                           improvements, routine operations, and the degree of on-site
                                           and centralized maintenance.
                                           Identify the total number of units or scope of services that will
           2.3      Quantities and         be needed to meet the need. Provide as much location
                    Location               information as possible, such as the number of workstations
                                           per Directorate or the location of servers.
                                           Identify the date by which the capability must be implemented
                                           at the first site. Identify the date by which all sites must
           2.4      Schedule
                                           achieve operational capability. Identify schedule constraints
                    Constraints
                                           associated with any interfacing AQS-200 Enterprise elements
                                           required to achieve full operational capability.
                                           No requirement should be entered into this section of the
       Ch. 3     Technical Performance     initial RD that is solution-specific or would unduly restrict the
                                           search for solutions to mission need.
                                           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.
           3.1      Operational and        Derived requirements that are discovered as necessary
                    Functional             implications of requirements stated in the Concept Paper
                    Requirements           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.
                                           Define performance requirements that are achievable,
           3.2      Performance
                                           measurable, and specified in operational terms whenever
                    Requirements
                                           practical. See Appendix B for examples.




                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                     Revision
                         AVS                                                    QPM #
                                                                                                           1
              Quality Management System                                    AQS 200-001-WI

                                                                                                    Page 134 of
Title: System Development Lifecycle                                     Date: 2/5/07
                                                                                                          350


                 Chapter/Section                                      Definition
                                           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
           3.3       Interfaces            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.
                                           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
       Ch 4      Physical Integration
                                           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.
                                           This chapter documents human/capability interface
                                           requirements for achieving optimum performance from a total
                                           capability perspective. These requirements are intended to
       Ch 5      Human Integration
                                           ensure that products are designed and appropriate for the
                                           human workforce that will operate, maintain, and support
                                           them.
       Ch 6      Security
                                           Define security requirements for accessing the new
                                           capability. If different levels of access are anticipated,
           6.1       User Security
                                           describe the type of users that will be given each level of
                                           access.
                                           Define security requirements relating to databases that will
           6.2       Database Security     satisfy this capability. This may include special password
                                           protection and encryption.
                                           Define security requirements relating to physical plant. This
           6.3       Physical Security     may include the storage of backup media, as well as server
                                           security.
       Ch 7      Test and Evaluation
                                           Designate critical operational functions that must be included
                                           in User Acceptance Testing (UAT) when determining whether
                                           a new capability is operationally acceptable. These features
           7.1       Critical Functions    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.



                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                      Revision
                           AVS                                                  QPM #
                                                                                                          1
                Quality Management System                                  AQS 200-001-WI

                                                                                                    Page 135 of
Title: System Development Lifecycle                                     Date: 2/5/07
                                                                                                         350


                 Chapter/Section                                      Definition
                                           Define special environmental issues that must be tested
                                           during UAT to determine if the capability operates as required
           7.2      Environmental
                                           in critical environments. For example, a mobile computing
                    Factors
                                           device may be required to operate on a factory floor, or
                                           outdoors during a storm.
                                           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,
       Ch 8      Implementation and
                                           installation and checkout, site integration, system shakedown,
                 Transition
                                           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.
                                           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
       Ch 9      Data
                                           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.
                                           This chapter lists the standards that are required for
       Ch 10 Standards
                                           implementation of this capability.
       Appendices
                                           Where applicable, specify a threshold value and an objective
                                           value for requirements. The threshold value is the minimum
                                           performance required for acceptable operational suitability
           A.       Minimum
                                           and effectiveness. The objective value represents a
                    Performance
                                           measurable increase in capability that has practical
                    Standards
                                           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.
                                           Develop a correlation matrix that maps by section number
           B.       Concept Paper
                                           and need statement where every need in the Concept is
                    Correlation Matrix
                                           addressed in the Requirements Document. Use table format.
           C.       Entity Relationship    The diagrams in this appendix, if used, support the data
                    Diagrams               requirements provided in Chapter 9.
                                           The diagrams in this appendix, if used, are a visual
                                           representation of the functional and interface requirements
           D.       Activity Diagrams
                                           documented in Chapter 3. Ideally, these diagrams will be
                                           consistent with partitions used in the chapter.
           E.       Definitions

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                      Revision
                           AVS                                                   QPM #
                                                                                                          1
                Quality Management System                                  AQS 200-001-WI

                                                                                                    Page 136 of
Title: System Development Lifecycle                                      Date: 2/5/07
                                                                                                          350


                Chapter/Section                                        Definition
           F.      Acronyms
           G.      References               Other documents or manuals that would be useful
                                            Specify those requirements from the Concept Paper that are
           H.      Residual Technical       not satisfied by the approved automation program. Resolution
                   Requirements             of these deferred requirements should occur via other
                                            Concept Papers or proposed product upgrades.
                                            Lists assumptions about requirements that are unknown or
           I.      Planning
                                            unspecified that will be used for project planning, scheduling,
                   Assumptions
                                            and resource estimating purposed.



    14.11. EXAMPLES OF OPERATIONAL AND FUNCTIONAL REQUIREMENTS
    The 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

    14.12. EXAMPLES OF CHARACTERISTICS AND PERFORMANCE REQUIREMENTS
    The following subsection titles are representative. Select and/or develop titles appropriate to the
    candidate solution or acquisition program.
          Subsection Heading                Description
                                            Define mission scenarios that may imply different levels of
                                            acceptable service (e.g., whether performance is different
          3.2.1 Service Levels              for normal and emergency back-up service, whether peak
                                            loading is substantially different from minimum or average
                                            loading).



                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                         Revision
                           AVS                                                   QPM #
                                                                                                             1
                Quality Management System                                   AQS 200-001-WI

                                                                                                        Page 137 of
Title: System Development Lifecycle                                       Date: 2/5/07
                                                                                                             350


                                            Define the period of time for the product to recover full
          3.2.2 Recovery
                                            service after power loss.
                                            Define reliability requirements (e.g., mean time between
                                            failure (MTBF)). Define maintainability requirements (e.g.,
          3.2.3 Reliability,
                                            mean time to repair (MTTR)). Define availability
            Maintainability, Availability
                                            requirements (e.g., full service availability, emergency
                                            service availability).
                                            Define requirements related to modularity and the ability of
                                            a product’s hardware and software components to be
          3.2.4 Enhanceability
                                            improved without requiring changes to components other
                                            than those being improved.
                                            Define requirements related to whether the product must
          3.2.5 Scalability                 provide for a range of capacity, functionality, and capability
                                            for a range of applications.
                                            Identify requirements concerning the selection of software
          3.2.6 Operational Software        (e.g., references to organizational software standards,
                                            whether software must be transferable between platforms).
                                            Define requirements concerning the selection of hardware
          3.2.7 Operational Hardware
                                            (e.g., references to organizational standards).
                                            Define requirements concerning how timely or current the
          3.2.7 Timeliness                  information supporting this capability must (e.g., real-time,
                                            as of the last business).

    14.13. REFERENCES
    The 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.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 138 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


                  FAA. The Federal Aviation Administration Integrated Capability Maturity Model
                   (FAA-iCMM), Version 1.0. November 1997.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                              QPM #
                                                                                                  1
              Quality Management System                              AQS 200-001-WI

                                                                                             Page 139 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                  350



    15     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.
    15.1. OVERVIEW
    This 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.
    15.1.1.        PURPOSE
    This section discusses the business need the CBA is trying to address, that is, the decision the
    AVS (or component) is trying to make.
    15.1.2.        SCOPE
    This section states the scope of CBA.
    15.1.3.        METHODOLOGY
    This section describes and discusses the CBA methodology employed and its relationship to the
    SDLC work pattern to be used by the project team.
    15.1.4.        AVS NEEDS
    This 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.
    15.1.5.        BACKGROUND
    This 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.


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                              QPM #
                                                                                                 1
              Quality Management System                              AQS 200-001-WI

                                                                                             Page 140 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                350


    Note: This section will be updated as the document is revised during the SDLC phases
    subsequent to System Concept Development Phase.
    15.1.6.        ARCHITECTURE
    This 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.
    15.1.7.        EXPECTED USEFUL LIFE
    This 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.
    15.2. OBJECTIVES AND PERFORMANCE MEASURES
    In 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.
    15.2.1.        SUPPORT FOR AVS MISSION
    This section describes how the project supports the Agency's Strategic Plans and overall
    mission.
    15.2.2.        STRATEGIC OBJECTIVES AND PERFORMANCE MEASURES
    Figure 15-1: 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-1: STRATEGIC LEVEL PERFORMANCE MEASURES
                                            Name of System
                     Objective                         Performance Measure




    15.2.3.        PROGRAM OBJECTIVES AND PERFORMANCE MEASURES
    Figure 15-2: Program Level Performance Measures, outlines the objectives and performance
    measures of the project that reflect program outcomes directly supporting strategic level
    objectives.
    FIGURE 15-2: PROGRAM LEVEL PERFORMANCE MEASURES
                                            Name of System


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                  Revision
                          AVS                                                 QPM #
                                                                                                      1
               Quality Management System                                 AQS 200-001-WI

                                                                                                 Page 141 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                     350


                     Objective                           Performance Measure




    15.2.4.        TACTICAL OBJECTIVES AND PERFORMANCE MEASURES
    Figure 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-3: TACTICAL LEVEL PERFORMANCE MEASURES
                                              Name of System
                     Objective                           Performance Measure




    15.3. ASSUMPTIONS, CONSTRAINTS, AND CONDITIONS
    This 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.
    15.3.1.        ASSUMPTIONS
    The 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.
    15.3.2.        CONSTRAINTS
    The 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.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 142 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    15.3.3.         CONDITIONS
    The 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
    15.4. FEASIBLE ALTERNATIVES
    This 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.
    15.4.1.         ALTERNATIVE 1
    This section briefly describes the alternative, its components, and how it will work.
    15.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 15.3, Assumptions, Constraints, and Conditions.
    FIGURE 15-4: ALTERNATIVE 1
                                               Alternative 1
                            Assumptions                              Implications


                             Constraints                             Implications


                             Conditions                              Implications




                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                   1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 143 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    15.4.1.2.       Advantages and Disadvantages
    This section discusses the advantages and disadvantages of this alternative.
    FIGURE 15-5: 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.
    15.5. COST ANALYSIS
    The 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.
    15.5.1.         COST CATEGORIES
    Figure 15-6: Cost-Related Terms, defines cost-related terms used in the Cost Analysis [the
    suggested line items may not be a complete list]:
    FIGURE 15-6: COST-RELATED TERMS
                       Terms and Definitions                                 Line Item
                                                             System development
      Nonrecurring Costs: Nonrecurring costs are             Prototypes
      developmental and capital investment costs incurred    Hardware purchase
      only once during the analysis, design, development,    Module design, development, and
      and implementation of the system.                        integration
                                                             System installation
                                                             Operations and Maintenance
                                                             Telecommunications
      Recurring Costs: Recurring costs are incurred more     Supplies
      than once throughout the life of the system and        Hardware and software upgrades,
      generally include operation and maintenance costs.        maintenance, and licenses
                                                             Personnel
                                                             Travel and training




                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                   Revision
                          AVS                                                QPM #
                                                                                                      1
               Quality Management System                                AQS 200-001-WI

                                                                                                Page 144 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                     350


    15.5.2.           PROJECT COST ANALYSIS
    The 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-7: 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.
    15.6. BENEFIT ANALYSIS
    This section analyzes the alternatives' individual ability to meet the goals of the project.
    15.6.1.           KEY BENEFIT TERMS
    Figure 15-8: 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 52, Glossary, and Section 53,
    Acronyms.
    FIGURE 15-8: KEY BENEFIT TERMS

       Term                                              Definition

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                          Revision
                            AVS                                                     QPM #
                                                                                                                 1
                 Quality Management System                                     AQS 200-001-WI

                                                                                                        Page 145 of
Title: System Development Lifecycle                                         Date: 2/5/07
                                                                                                             350


       Term                                                   Definition

                    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
    Tangible        analysis, tangible benefits are expressed in dollar values so that a valid comparison can be
    Benefits        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.

                    Benefits are expressed in terms of improved mission performance, Improved decision-
                    making, or more reliable or usable information. These Benefits may be quantifiable, but
    Intangible      cannot be expressed in dollar values.
    Benefits        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.

    15.6.2.          TANGIBLE BENEFITS
    This 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-9: Tangible Benefit 1, and Figure 15-10: Annual Savings (Based on Average X Million
    Transactions per Annum), detail this information. Repeat this for each tangible benefit.
    FIGURE 15-9: TANGIBLE BENEFIT 1
                                                    Measurement
                      Current Value                   Alternative 1                 Alternative n


                         Savings

    FIGURE 15-10: 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

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                               QPM #
                                                                                                 1
              Quality Management System                               AQS 200-001-WI

                                                                                             Page 146 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                350


                          Dollar Savings (Based on FTE Salary of $X per Annum)


                    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.
    15.6.3.         SUMMARY OF TANGIBLE BENEFITS
    Figure 15-11: Tangible Benefits, summarizes the quantifiable benefit value for each alternative.
    FIGURE 15-11: TANGIBLE BENEFITS
                                               Alternative 1              Alternative n
              Benefit 1
              Benefit n
              Total Benefit

    Figure 15-12: Summary of Project Tangible Benefits: Expected Return, summarizes the tangible
    benefits described above.
    Figure 15-13: 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-12: SUMMARY OF PROJECT TANGIBLE BENEFITS: EXPECTED RETURN
                                            Tangible Benefit 1
                                            FY99           FY00        FY01          Total
              Alternative 1
              Alternative n
                                             Tangible Benefit n
                                            FY99           FY00        FY01          Total
              Alternative 1
              Alternative n
                                               Total Benefits
                                            FY99           FY00        FY01          Total
              Alternative 1

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                                QPM #
                                                                                                   1
              Quality Management System                                AQS 200-001-WI

                                                                                              Page 147 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


                                              Tangible Benefit 1
              Alternative n

    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.
    15.6.4.         INTANGIBLE BENEFITS
    Although 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-13: INTANGIBLE BENEFITS ALTERNATIVE 1
                              Intangible Benefits                        Description
              Intangible Benefit 1
              Intangible Benefit n

    FIGURE 15-14: INTANGIBLE BENEFITS ALTERNATIVE N
                              Intangible Benefits                        Description
              Intangible Benefit 1
              Intangible Benefit n

    For each alternative, include a table in the same format as the above exhibits.
    15.6.5.         SUMMARY OF INTANGIBLE BENEFITS
    Figure 15-15: Summary of Intangible Benefits-- Expected Return, summarizes the values of
    intangible benefits.
    FIGURE 15-15: SUMMARY OF INTANGIBLE BENEFITS-- EXPECTED RETURN
                     Intangible Benefits             Alternative 1           Alternative n
              Intangible Benefit 1
              Intangible Benefit 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.
    15.7. COMPARISON OF COSTS AND BENEFITS
    This 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

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                    Revision
                         AVS                                                    QPM #
                                                                                                       1
              Quality Management System                                 AQS 200-001-WI

                                                                                                   Page 148 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                      350


    of this comparison is to identify if tangible and intangible benefits outweigh the total cost of the
    system.
    15.7.1.         TANGIBLE BENEFITS
    Figure 15-16: Project Cost to Tangible Benefit Comparison, compares the costs and tangible
    benefits of the Project.
    FIGURE 15-16: PROJECT COST TO TANGIBLE BENEFIT COMPARISON
                                                                Alternative 1      Alternative n
              Total Tangible Benefits
              Total Costs
              Difference Between Costs and Benefits

    15.7.2.         INTANGIBLE BENEFITS
    Figure 15-17: Intangible Benefit Comparison-- Expected Return, compares the intangible
    benefits of the Project.
    FIGURE 15-17: INTANGIBLE BENEFIT COMPARISON-- EXPECTED RETURN
                                                      Alternative 1             Alternative n
              Intangible Benefits



    15.7.3.         CONCLUSION
    As 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.
    15.8. SENSITIVITY ANALYSIS
    A 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.
    15.8.1.         KEY SOURCES OF UNCERTAINTY
    Figure 15-18: 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.



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                   Revision
                          AVS                                               QPM #
                                                                                                      1
               Quality Management System                               AQS 200-001-WI

                                                                                                 Page 149 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                     350


    FIGURE 15-18: SENSITIVITY RESULTS
                    Key Sources of              Extent of          Nature of
                                                                                    Implications
                     Uncertainty                 Impact             Impact




    15.8.2.        SENSITIVITY RESULTS
    Each 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.
    15.9. RESULTS OF THE ANALYSIS
    The 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.
    15.10. REFERENCES AND DOCUMENTATION
    Documents 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.
    15.10.1.       DOCUMENTATION
    List all documents used for this analysis. This list should include titles, authors, publishers, and
    dates.
    15.10.2.       INTERVIEWS
    List all interviews conducted for this analysis. This list should include names and organizations.
    15.11. GLOSSARY AND ACRONYMS
    The 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.
    15.11.1.       GLOSSARY
    Provide a list of all system-specific terms, and their definitions, used in this document.
    15.11.2.       ACRONYMS
    Provide a list of all acronyms used in this document.



                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                 1
             Quality Management System                                AQS 200-001-WI

                                                                                             Page 150 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                350


    15.12. COST-BENEFIT ANALYSIS OUTLINE
    Cover Page
    Table of Contents
    Executive Summary
    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)

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 151 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


           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
           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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                               QPM #
                                                                                                 1
             Quality Management System                                AQS 200-001-WI

                                                                                             Page 152 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                350



    16     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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                         AVS                                                 QPM #
                                                                                                     1
              Quality Management System                                 AQS 200-001-WI

                                                                                                Page 153 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                    350


    16.1. INTRODUCTION
    16.1.1.        ORIGIN OF REQUEST
    This section identifies the originator and describes the circumstances that precipitated this
    project request. Provide the objectives of the Feasibility Study in clear, measurable terms.
    16.1.2.        EXPLANATION OF REQUIREMENT
    This 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.
    16.1.3.        ORGANIZATION INFORMATION
    This 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.
    16.1.4.        GLOSSARY
    Provide 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.
    16.2. EVALUATION CRITERIA
    This 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.
    16.3. ALTERNATIVE DESCRIPTIONS
    This 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.
    16.3.1.        ALTERNATIVE MODEL
    This 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.



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                              QPM #
                                                                                                 1
              Quality Management System                              AQS 200-001-WI

                                                                                             Page 154 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                350


    16.3.2.        DESCRIPTION
    This section states the required and desirable features, and provides a concise narrative of the
    effects of implementing this alternative.
    16.4. ALTERNATIVE EVALUATION
    This section provides a systematic comparison of the alternatives and documents potential
    problems resulting from the implementation of each.
    16.5. RECOMMENDATION
    This 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.
    16.6. FEASIBILITY STUDY OUTLINE
    Cover 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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                      Revision
                          AVS                                                   QPM #
                                                                                                            1
               Quality Management System                                   AQS 200-001-WI

                                                                                                    Page 155 of
Title: System Development Lifecycle                                      Date: 2/5/07
                                                                                                        350



    17     RISK MANAGEMENT PLAN

    17.1. INTRODUCTION
    17.1.1.        PURPOSE
    In 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.
    17.1.2.        BACKGROUND
    This 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
    17.1.3.        SCOPE
    This 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.
    17.1.4.        POLICY
    Include 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.
    17.1.5.        APPROACH
    In 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).
    17.2. RISK IDENTIFICATION LIST
    The 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
                  The correctness, integrity, maintainability, performance, reliability, security,
                   testability, and usability of the SDLC deliverables
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                     Revision
                          AVS                                                QPM #
                                                                                                        1
               Quality Management System                                AQS 200-001-WI

                                                                                                Page 156 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                       350


                  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.
    17.3. RISK ASSESSMENT
    The 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.
    17.4. RISK ACTION PLAN
    Review 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
    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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                  Revision
                        AVS                                                   QPM #
                                                                                                      1
             Quality Management System                                   AQS 200-001-WI

                                                                                                 Page 157 of
Title: System Development Lifecycle                                    Date: 2/5/07
                                                                                                     350


    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.
    17.5. RISK MANAGEMENT OUTLINE
    1.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




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 158 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350



    18     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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                          AVS                                               QPM #
                                                                                                    1
               Quality Management System                               AQS 200-001-WI

                                                                                                Page 159 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


                  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.
    18.1. BACKGROUND AND OBJECTIVES
    18.1.1.        STATEMENT OF NEED
    This section introduces the plan with a brief statement of need. This section should discuss
    feasible acquisition alternatives and any related in-house efforts.
    18.1.2.        APPLICABLE CONDITIONS
    This 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.
    18.1.3.        COST
    This 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.
    18.1.4.        LIFE-CYCLE COST
    This 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.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                               AQS 200-001-WI

                                                                                              Page 160 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350


    18.1.5.        DESIGN-TO-COST
    This 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.
    18.1.6.        APPLICATION OF SHOULD-COST
    This section discusses the application of should-cost analysis to the acquisition, as per FAR
    15.810.
    18.1.7.        CAPABILITY OR PERFORMANCE
    This section specifies the required capabilities or performance characteristics of the products
    being acquired, and states how they are related to the need.
    18.1.8.        DELIVERY OR PERFORMANCE-PERIOD REQUIREMENTS
    This 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.
    18.1.9.        TRADE-OFFS
    This section discusses the expected consequences of trade-offs among the various cost,
    capability, performance, and schedule goals.
    18.1.10.       RISKS
    This 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.
    18.1.11.       ACQUISITION STREAMLINING
    This 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.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                                QPM #
                                                                                                   1
              Quality Management System                                AQS 200-001-WI

                                                                                              Page 161 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    18.2. PLAN OF ACTION
    18.2.1.        SOURCES
    This 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.
    18.2.2.        COMPETITION
    This 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.
    18.2.3.        SOURCE SELECTION PROCEDURES
    This 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.
    18.2.4.        CONTRACTING CONSIDERATIONS
    This 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.
    18.2.5.        BUDGETING AND FUNDING
    This section describes how budget estimates were derived, and discusses the schedule for
    obtaining adequate funds at the time they are required.
    18.2.6.        PRODUCT DESCRIPTIONS
    This section explains, in accordance with FAR Part 11, the choice of product description types
    to be used in the acquisition.
    18.2.7.        PRIORITIES, ALLOCATIONS, AND ALLOTMENTS
    This 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.
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                          AVS                                               QPM #
                                                                                                   1
               Quality Management System                               AQS 200-001-WI

                                                                                              Page 162 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    18.2.8.        CONTRACTOR VERSUS GOVERNMENT PERFORMANCE
    This 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.
    18.2.9.        INHERENTLY GOVERNMENTAL FUNCTIONS
    This 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.
    18.2.10.       MANAGEMENT INFORMATION REQUIREMENTS
    This section discusses the management systems that will be used by the Government to
    monitor the contractor's effort.
    18.2.11.       MAKE OR BUY
    This section discusses considerations given to make-or-buy programs, as per FAR 15.7.
    18.2.12.       TEST AND EVALUATION
    This 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.
    18.2.13.       LOGISTICS CONSIDERATIONS
    This 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.
    18.2.14.       GOVERNMENT-FURNISHED PROPERTY
    This 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.
    18.2.15.       GOVERNMENT-FURNISHED INFORMATION
    This section discusses any Government information, such as manuals, drawings, and test data,
    to be provided to prospective offerors and contractors.


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

                                                                                              Page 163 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350


    18.2.16.       ENVIRONMENTAL AND ENERGY CONSERVATION OBJECTIVES
    This 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.
    18.2.17.       SECURITY CONSIDERATIONS
    This section discusses, for acquisitions dealing with security-related matters, how adequate
    security will be established, maintained, and monitored.
    18.2.18.       OTHER CONSIDERATIONS
    This 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.
    18.2.19.       MILESTONES FOR THE ACQUISITION CYCLE
    This 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.
    18.2.20.       ACQUISITION PLAN CONTACTS
    This section lists the individuals who participated in preparing the Acquisition Plan, and provides
    contact information for each.
    18.3. ACQUISITION PLAN OUTLINE
    Cover 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)
                   1.3.1 Life Cycle Cost(s)
                   1.3.2 Design-to-Cost
                   1.3.3 Application of Should-Cost

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 164 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


           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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                                  QPM #
                                                                                                     1
              Quality Management System                                   AQS 200-001-WI

                                                                                             Page 165 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                 350



    19     CONFIGURATION MANAGEMENT PLAN

    19.1. INTRODUCTION
    Provide 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.
    19.1.1.        PURPOSE
    Describe why this CM plan was created, what it accomplishes, and how it is used.
    19.1.2.        SCOPE
    Define the scope of CM planning.
    19.1.3.        SYSTEM DESCRIPTION
    Briefly 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.
    19.1.4.        DEFINITIONS
    Define the terms that appear in the CM plan.
    19.1.5.        REFERENCE DOCUMENTS
    List the documents that are referenced to support the CM process including any project or
    standards documents referenced in the body of the CM plan.
    19.2. ORGANIZATION
    Identify 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.
    19.2.1.        CM ACTIVITIES
    Identify all CM functions required to manage the configuration of the system.
    19.2.2.        CM RESPONSIBILITIES
    List CM responsibilities that are required to support this project.
    19.3. CONFIGURATION IDENTIFICATION
    Explain 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                              QPM #
                                                                                                  1
              Quality Management System                              AQS 200-001-WI

                                                                                             Page 166 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                  350


    19.3.1.        CONFIGURATION ITEM IDENTIFICATION
    Identify the CIs to be controlled and specify a means of identifying changes to the CIs and
    related baselines.
    19.3.2.        IDENTIFICATION CONVENTIONS
    Describe the identification (numbering) criteria for the software and hardware structure, and for
    each document or document set.
    19.3.3.        NAMING CONVENTIONS
    Provide details of the file naming convention to be used on the project and how file configuration
    integrity will be maintained.
    19.3.4.        LABELS
    Describe the requirements for labeling media and application software.
    19.3.5.        CONFIGURATION BASELINE MANAGEMENT
    Describe what baselines are to be established. Explain when and how they will be defined and
    controlled.
    19.4. CONFIGURATION CONTROL
    Explain that configuration change management is a process for managing configuration
    changes and variances in configurations.
    19.4.1.        CHANGE MANAGEMENT
    Define the process for controlling changes to the system baselines and for tracking the
    implementation of those changes.
    19.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.
    19.4.3.        INTERFACE MANAGEMENT
    Identify 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.
    19.5. CONFIGURATION STATUS ACCOUNTING
    Explain 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.



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

                                                                                              Page 167 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350


    19.6. CONFIGURATION AUDITS
    Describe how peer review audits and formal audits will be accomplished.
    19.7. REVIEWS
    Describe how the technical reviews relate to the establishment of baselines and explain the role
    of CM in these reviews.
    19.8. CM PLAN MAINTENANCE
    Describe 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.
    19.9. DATA MANAGEMENT
    19.9.1.        LIBRARIES
    Identify the libraries and the media under control, the requirements for the control of
    documentation, and how access control is to be managed.
    19.9.2.        AUTOMATED TOOLS
    Describe any automated tools used.
    19.9.3.        VERSION CONTROL
    Describe the processes in place to control the amount and number of versions documented by
    this CM Plan.
    19.9.4.        WORK SPACE MANAGEMENT
    Describe the processes used for automated software source case control tools.
    19.9.5.        BUILD MANAGEMENT
    Describe the controls in place to manage the building of executable code.
    19.9.6.        DOCUMENTATION MANAGEMENT
    Describe the processes in place for documentation management and who is responsible for
    them.
    19.10. SUBCONTRACTOR CONTROL
    Subcontractors 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.

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 168 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


    19.11. CONFIGURATION MANAGEMENT PLAN OUTLINE
    Cover 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

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 169 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


           9.3 Version Control
           9.4 Work Space Management
           9.5 Build Management
           9.6 Documentation Management
    10. Subcontractor Control




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                  Revision
                         AVS                                                   QPM #
                                                                                                     1
              Quality Management System                                   AQS 200-001-WI

                                                                                                 Page 170 of
Title: System Development Lifecycle                                     Date: 2/5/07
                                                                                                    350



    20      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.
    20.1. GENERAL
    20.1.1.         PURPOSE
    Establish 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.
    20.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.
    20.1.3.         OBJECTIVE
    Discuss 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.
    20.1.4.         GLOSSARY
    Provide definitions for terms and acronyms used within the QA plan.
    20.2. ORGANIZATION
    Provide 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.
    20.2.1.         CUSTOMER
    Describe the partnership activities performed by QA in support of contract performance.


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                             QPM #
                                                                                                 1
              Quality Management System                             AQS 200-001-WI

                                                                                             Page 171 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


    20.2.2.        SYSTEM DEVELOPMENT
    Describe 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.
    20.2.3.        TEST AND EVALUATION
    Describe 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.
    20.2.4.        CONFIGURATION MANAGEMENT
    Describe 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.
    20.2.5.        QA ROLES AND RESPONSIBILITIES
    Describe the organizational and functional alignment of the QA staff. Describe the roles and
    responsibilities at the management, team leader, and specialist levels.
    20.3. PROCESSES
    Provide 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.
    20.3.1.        GENERAL
    Describe QA's role in performing reviews and audits associated with deliverables and with
    collections of deliverables making up an SDLC phase.
    20.3.2.        PEER REVIEW
    Commit to QA participation in the peer review process to identify, document, measure, and
    eliminate defects in a work product.
    20.3.3.        PROCESS REVIEW
    Describe 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.
    20.4. PROBLEM REPORTING AND CORRECTIVE ACTION
    Describe 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.
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                             QPM #
                                                                                                 1
              Quality Management System                             AQS 200-001-WI

                                                                                             Page 172 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


    20.4.1.        QUALITY ACTION REPORTS
    Describe preparation of QARs to document anomalies, violations of program standards, or
    potential problems as identified during any point in the SDLC.
    20.4.2.        QA ESCALATION PROCEDURES
    Describe the QA escalation procedures that bring high-risk or long-standing, unresolved
    noncompliance tracking issues to senior management's attention.
    20.4.3.        QA REPORT FORMATS
    Describe the report formats that formally document and transmit information from QA audits
    and/or assessment reviews.
    20.5. TOOLS, TECHNIQUES, AND METHODOLOGIES
    Identify 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.
    20.5.1.        SDLC
    Describe 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.
    20.5.2.        POLICIES
    Describe QA's role in developing policy statements that expand, enhance, or clarify SDLC
    requirements, or that introduce new or enhanced standards.
    20.5.3.        STANDARDS
    Describe 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.
    20.5.4.        TOOLS
    Describe the tool sets that QA employs in the conduct of administrative and technical functions.
    20.6. QUALITY ASSURANCE PLAN OUTLINE
    Cover Page
    Table of Contents
    1. General
           1.1 Purpose
           1.2 Reference
           1.3 Objective
           1.4 Glossary

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 173 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


    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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

                                                                                              Page 174 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350



    21     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
    21.1. STATEMENT OF NEED
    Indicate why this information, process, or procedure should be automated at the national level
    and what function it would fulfill.
    21.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.
    21.3. WORK TO BE AUTOMATED
    Briefly describe the major functions of the project. Please do not describe the automation
    process.
    21.4. COSTS AND BENEFITS
    Describe possible benefits of automating this information, procedure or process.



                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 175 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


    21.5. OPTIONS CONSIDERED
    This is optional. If you have ideas on how this could be automated, please include.
    21.6. HOW THE FUNCTION IS CURRENTLY PERFORMED
    This is optional.
    21.7. REQUESTER’S NAME, ROUTING SYMBOL AND POSITION
    Include the requester’s information.


    21.8. CONCEPT PAPER
    Cover 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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 176 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350



    22     SYSTEM SECURITY PLAN

    Reference the NIST Special Publication 800-18, Guide for Developing Security Plans for
    Information Technology Systems, dated November 1998.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                 QPM #
                                                                                                    1
              Quality Management System                                 AQS 200-001-WI

                                                                                               Page 177 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350



    23     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.
    23.1. INTRODUCTION
    This section is a description of the project management plan purpose and scope.
    23.2. PROJECT DESCRIPTION
    This 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.
    23.3. PROJECT BACKGROUND
    This 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.
    23.3.1.        PROJECT DEVELOPMENT STRATEGY
    This 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.
    23.3.2.        ORGANIZATION OF THE PROJECT PLAN
    This section briefly describes the organization of the Project Management Plan.
    23.4. POINTS OF CONTACT
    This 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.
    23.5. PROJECT REFERENCES
    This section is a bibliography of key project references and deliverables produced before this
    point. For example, these references might include cost-benefit analyses, existing

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                          AVS                                                QPM #
                                                                                                    1
               Quality Management System                                AQS 200-001-WI

                                                                                               Page 178 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                   350


    documentation describing internal processes, or existing documentation of the system if the
    project is a conversion.
    23.6. GLOSSARY
    This 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.
    23.7. ORGANIZATION AND RESPONSIBILITIES
    This 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
    23.8. PROJECT DESCRIPTION, SCHEDULE AND RESOURCES
    This 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.
    23.8.1.        PROJECT WORK BREAKDOWN STRUCTURE
    This 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.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 179 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    23.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.
    23.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.
    23.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.
    23.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.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

                                                                                             Page 180 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350


    23.8.2.        RESOURCE ESTIMATES
    This 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.
    23.8.3.        SCHEDULE
    This 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.
    23.8.4.        RESOURCE ACQUISITION PLAN
    This 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.
    23.8.5.        COMMUNICATION PLAN
    This 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.
    23.8.6.        PROJECT STANDARDS AND PROCEDURES
    While 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.


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                QPM #
                                                                                                    1
              Quality Management System                                AQS 200-001-WI

                                                                                               Page 181 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


    23.8.7.           RISK MANAGEMENT
    For 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.
    23.9. SECURITY AND PRIVACY
    This section should review security and privacy requirements for the project and should ensure
    that the Project Plan reflects these requirements.
    23.9.1.           PRIVACY ISSUES
    This 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.
    23.9.2.           COMPUTER SECURITY ACTIVITIES
    This 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.
    23.10. PROJECT MANAGEMENT PLAN OUTLINE
    Cover 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 Resources
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 182 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


           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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

                                                                                             Page 183 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350



    24     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.
    24.1. BACKGROUND AND INTRODUCTION
    This 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.
    24.1.1.        STATEMENT OF PROBLEM
    Describe the problem in concise terms.
    24.1.2.        PROPOSED SOLUTION
    Describe the proposed solution that influences the V&V needs and approach.
    24.1.3.        REFERENCES AND RELATED DOCUMENTS
    List 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.
    24.2. V&V REQUIREMENTS AND MEASUREMENT CRITERIA
    This 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.
    24.2.1.        V&V REQUIREMENTS AND THEIR IMPORTANCE
    Briefly describe the functional, performance, reliability or other requirements and why they are
    important to this system or subsystem.
    24.2.2.        MEASUREMENT CRITERIA FOR EACH REQUIREMENT
    Briefly describe general, product specific or phase specific measurement criteria for the above
    requirements.
    24.2.3.        REFERENCES AND RELATED DOCUMENTS
    List any documents that the above might be referenced in (if a large document). These could be
    the SBD, CBA, Feasibility Study, etc.
    24.3. PHASE BY PHASE V&V PLANS
    First, 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.
    24.3.1.        PROJECT BACKGROUND AND SUMMARY INFORMATION
    Project Phases and products
    Major reviews (both management and technical)
                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 184 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


    24.3.2.        PLANNING PHASE V&V ACTIVITIES
    For 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
    24.3.3.        REQUIREMENTS ANALYSIS PHASE


    24.3.4.        DESIGN PHASE


    24.3.5.        DEVELOPMENT PHASE


    24.3.6.        INTEGRATION AND TEST PHASE


    24.3.7.        IMPLEMENTATION PHASE


    24.3.8.        OPERATIONS AND MAINTENANCE PHASE


    Appendix A Project and Environmental Considerations


    Appendix B Technique and Tool Selection Information
    24.4. VERIFICATION AND VALIDATION PLAN OUTLINE
    Cover Page
    Table of Contents
    1.0 Background and Introduction
           1.1 Statement of Problem
           1.2 Proposed Solution
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 185 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


           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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                          AVS                                               QPM #
                                                                                                   1
               Quality Management System                               AQS 200-001-WI

                                                                                              Page 186 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350



    25     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.
    25.1. INTRODUCTION
    This 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.
    25.1.1.        EXECUTIVE SUMMARY
    This section describes the technical plan summary and applicability. If applicable, it also lists
    major subordinate plans.
    25.1.2.        TABLE OF CONTENTS
    25.1.3.        PROJECT SUMMARY
    Briefly describe the project, to include complexities and challenges that are addressed by the
    technical development effort.
    25.1.4.        SCOPE
    Describe the applicability of the SEMP and assign general responsibilities for the required
    activities shown in the SEMP.
    25.1.5.        APPLICABLE DOCUMENTS
    List by title, version number, and issue date applicable documents to the technical management
    efforts described in the SEMP.
    25.2. SYSTEM ENGINEERING PROCESS
    This 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.
    25.2.1.        SYSTEMS ENGINEERING PROCESS PLANNING
    This 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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 187 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


                  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
    25.2.2.        REQUIREMENTS ANALYSIS
    This 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.
    25.2.3.        FUNCTIONAL ANALYSIS/ALLOCATION
    This section addresses the methods and tools used analyze the project requirements and
    allocate them down into project component functional requirements.
    25.2.4.        SYNTHESIS
    This section addresses the methods and tools used to analyze the functional requirements and
    allocate those requirements to a physical project component.
    25.2.5.        SYSTEM ANALYSIS
    This 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.
    25.2.6.        SYSTEM CONTROL
    This 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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                                QPM #
                                                                                                    1
               Quality Management System                                AQS 200-001-WI

                                                                                              Page 188 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                 350


                     Requirements control
    25.3. TECHNOLOGY REFRESHMENT
    This 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.
    25.4. IMPLEMENTATION PLANNING
    This 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
    25.5. SPECIALTY ENGINEERING PLANNING
    This section outlines any special subject applicable to the project not covered in a previous
    section.
    25.6. SYSTEMS ENGINEERING MANAGEMENT PLAN OUTLINE
    Cover 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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 189 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


    4. Implementation Planning
    5. Specialty Engineering Planning




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                               QPM #
                                                                                                    1
                Quality Management System                               AQS 200-001-WI

                                                                                               Page 190 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350



    26     FUNCTIONAL REQUIREMENTS DOCUMENT

    26.1. INTRODUCTION
    The 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.
    26.1.1.         PROJECT DESCRIPTION
    Provide a brief overview of the project.
    26.1.1.1.       Background
    Summarize the conditions that created the need for the application.
                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                               QPM #
                                                                                                    1
                Quality Management System                               AQS 200-001-WI

                                                                                               Page 191 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


    26.1.1.2.       Purpose
    Describe the business objectives and business processes from the CONOPS document and the
    CBA that this application supports.
    26.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.
    26.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.
    26.1.2.         POINTS OF CONTACT
    List 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


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                  Revision
                          AVS                                                 QPM #
                                                                                                     1
               Quality Management System                                AQS 200-001-WI

                                                                                                Page 192 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                    350


    26.1.3.        DOCUMENT REFERENCES
    Name 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.
    26.2. FUNCTIONAL REQUIREMENTS
    The functional requirements describe the core functionality of the application. This section
    includes the data and functional process requirements.
    26.2.1.        DATA REQUIREMENTS
    Describe 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.
    26.2.2.        FUNCTIONAL PROCESS REQUIREMENTS
    Process 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
    26.3. OPERATIONAL REQUIREMENTS
    Operational 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.




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                      Revision
                           AVS                                                   QPM #
                                                                                                          1
                Quality Management System                                   AQS 200-001-WI

                                                                                                    Page 193 of
Title: System Development Lifecycle                                      Date: 2/5/07
                                                                                                        350


    26.3.1.         SECURITY
    The 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.
    26.3.2.         AUDIT TRAIL
    List the activities that will be recorded in the application's audit trail. For each activity, list the
    data to be recorded.
    26.3.3.         DATA CURRENCY
    Data 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.
    26.3.4.         RELIABILITY
    Reliability 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?

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                    Revision
                          AVS                                                 QPM #
                                                                                                       1
               Quality Management System                                 AQS 200-001-WI

                                                                                               Page 194 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                      350


    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.
    26.3.5.        RECOVERABILITY
    Recoverability 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?
    26.3.6.        SYSTEM AVAILABILITY
    System 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.
    26.3.7.        FAULT TOLERANCE
    Fault 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.
    26.3.8.        PERFORMANCE
    Describe the requirements for the following:

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 195 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


                  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)
    26.3.9.        CAPACITY
    List 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.
    26.3.10.       DATA RETENTION
    Describe 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."
    26.4. REQUIREMENTS TRACEABILITY MATRIX
    The 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:
    26.4.1.        REQUIREMENT DESCRIPTION
    26.4.2.        REQUIREMENT REFERENCE IN FRD
    26.4.3.        VERIFICATION METHOD
    26.4.4.        REQUIREMENT REFERENCE IN TEST PLAN
    26.5. GLOSSARY
    Include business terms peculiar to the application. Do not include any technology-related terms.
    26.6. FUNCTIONAL REQUIREMENTS DOCUMENT OUTLINE
    Cover Page
    Table of Contents
    1.0 Introduction
           1.1 Project Description
                   1.1.1 Background
                   1.1.2 Purpose
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 196 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


                   1.1.3 Assumptions and Constraints
                   1.1.4 Interfaces to External Systems
           1.2 Points of Contact
           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




                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                                QPM #
                                                                                                  1
             Quality Management System                                AQS 200-001-WI

                                                                                             Page 197 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350



    27     TEST AND EVALUATION MASTER PLAN

    27.1. INTRODUCTION
    The 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.
    27.2. PURPOSE
    In 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.
    27.3. BACKGROUND
    This 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.
    27.4. SCOPE
    This 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.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                           AVS                                               QPM #
                                                                                                    1
                Quality Management System                               AQS 200-001-WI

                                                                                               Page 198 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                   350


    27.5. GLOSSARY
    This 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.
    27.6. LIMITATIONS AND TRACEABILITY
    This 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.
    27.6.1.         LIMITATIONS
    This 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).
    27.6.2.         TRACEABILITY
    This 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.
    27.7. TEST PLANS
    This 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.
    27.7.1.         TEST LEVELS
    This 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.
    27.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
                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                               QPM #
                                                                                                   1
                Quality Management System                                AQS 200-001-WI

                                                                                               Page 199 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    from the tests) may be delivered as part of the final Test Plan, with the integration test analysis
    report or as an appendix.
    27.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.
    27.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.
    27.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.
    27.7.2.         TEST ENVIRONMENT AND SCHEDULES
    This section provides a brief description of the inputs, outputs, and functions of the software
    being tested.
    27.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.
    27.7.2.2.       Milestones
    This section lists the milestone events and dates for the testing.
    27.7.2.3.       Organizations and Locations
    This section provides information on the participating organizations and the location where the
    software will be tested.
    27.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.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 200 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    27.7.2.5.       Resource Requirements
    This section and associated statements define the resource requirements for the testing.

    27.7.2.5.1.     Equipment
    This section shows the expected period of use, types, and quantities of equipment needed.

    27.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.

    27.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.
    27.7.2.6.       Testing Material
    This section describes the documents needed to perform the tests. It could include software,
    resources, data and other information.
    27.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.
    27.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.

    27.7.2.8.1.     Methodology
    This section describes the general methodology or testing strategy for each type of testing
    described in this Test Plan.

    27.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.




                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                     1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 201 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    27.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.

    27.7.2.8.4.     Data Recording
    This section describes the method used for recording test results and other information about
    the testing.

    27.7.2.8.5.     Constraints
    This section indicates anticipated limitations on the test because of test conditions, such as
    interfaces, equipment, personnel, and databases.

    27.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.

    27.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.
    27.8. TEST DESCRIPTION
    This 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.
    27.8.1.         TEST NAME
    This 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.
    27.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.
    27.8.1.2.       Control
    Describe the test control-such as manual, semiautomatic, or automatic insertion of inputs;
    sequencing of operations; and recording of results.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                     1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 202 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    27.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.
    27.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.
    27.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.
    27.9. TEST AND EVALUATION MASTER PLAN OUTLINE
    Cover 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 Requirements
                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 203 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


                            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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                               QPM #
                                                                                                  1
              Quality Management System                               AQS 200-001-WI

                                                                                             Page 204 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350



    28     INTERFACE CONTROL DOCUMENT

    28.1. SCOPE
    This 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.
    28.2. SYSTEM IDENTIFICATION
    The 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.
    28.2.1.        SYSTEM 1
    The 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.
    28.2.2.        SYSTEM 2
    The information provided should be similar to that provided in Section 1.1.1
    28.3. DOCUMENT OVERVIEW
    Sample 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:

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                   1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 205 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


                   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
    28.4. APPLICABLE DOCUMENTS
    This 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.
    28.5. DESCRIPTION
    Provide a description of the interface between <System1> and <System 2>.
    28.5.1.         SYSTEM OVERVIEW
    This 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.
    28.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.


    28.5.2.         FUNCTIONAL ALLOCATION
    Briefly 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.
    28.5.3.         DATA TRANSFER
    Briefly 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.
                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                         AVS                                               QPM #
                                                                                                    1
              Quality Management System                                AQS 200-001-WI

                                                                                             Page 206 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                    350


    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.
    28.5.4.        TRANSACTIONS
    Briefly 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.
    28.5.5.        SECURITY AND INTEGRITY
    If 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.
    28.6. DETAILED INTERFACE REQUIREMENTS
    This 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.

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                   1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 207 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    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.
    28.6.1.         INTERFACE 1 REQUIREMENTS
    Briefly 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.
    28.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.
    28.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.

    28.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

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 208 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


                   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)

    28.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)
    28.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.
                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                   1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 209 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    28.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.

    28.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.
    28.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.
    28.6.2.         INTERFACE 2 REQUIREMENTS
    When 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.
    28.7. QUALIFICATION METHODS
    This 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.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                               QPM #
                                                                                                   1
               Quality Management System                               AQS 200-001-WI

                                                                                              Page 210 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


                  Special qualification methods: Any special qualification methods for the
                   interfacing entities, such as special tools, techniques, procedures, facilities, and
                   acceptance limits.
    28.8. NOTES
    This section contains any general information that aids in understanding the document (e.g.,
    background information, glossary).
    28.9. APPENDICES
    Appendices may be used to provide information published separately for convenience in
    document maintenance (e.g., acronyms, abbreviations).
    28.10. APPROVALS
    A 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_____________
    Printed name and title _______________________________________________
    System 1 Configuration Control Board ______________________Date_____________
    Printed name and title _______________________________________________
    System 2 Configuration Control Board ______________________Date_____________
    Printed name and title _______________________________________________
    28.11. RECORD OF CHANGES
    This 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.
    28.12. INTERFACE CONTROL DOCUMENT OUTLINE
    1.0 Scope
           1.1 System Identification

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                        AVS                                                QPM #
                                                                                                   1
             Quality Management System                                AQS 200-001-WI

                                                                                               Page 211 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


                    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




                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 212 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350



    29     SECURITY RISK ASSESSMENT

    Reference the NIST Special Publication 800-30, Risk Management Guide for Information
    Technology Systems, dated 2001.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 213 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350



    30     CONTINGENCY PLAN

    Reference the NIST Special Publication 800-34, Contingency Planning Guide for Information
    Technology Systems, dated June 2002.




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                  QPM #
                                                                                                   1
              Quality Management System                                   AQS 200-001-WI

                                                                                              Page 214 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350



    31     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.
    31.1. INTRODUCTION
    This section provides a brief description of introductory material.
    31.1.1.        PURPOSE AND SCOPE
    This section describes the purpose and scope of the Conversion Plan. Reference the
    information system name and provide identifying information about the system undergoing
    conversion.
    31.1.2.        POINTS OF CONTACT
    This 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.
    31.1.3.        PROJECT REFERENCES
    This 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.
    31.1.4.        GLOSSARY
    This 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.
    31.2. CONVERSION OVERVIEW
    This section provides an overview of the aspects of the conversion effort, which are discussed
    in the subsequent sections.
    31.2.1.        SYSTEM OVERVIEW
    This 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.
    31.2.2.        SYSTEM CONVERSION OVERVIEW
    This section provides an overview of the planned conversion effort.



                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 215 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    31.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.
    31.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.
    31.2.2.3.       Conversion Strategy
    This section describes the strategies for conversion of system hardware, software, and data.

    31.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.

    31.2.2.3.2.     Software Conversion Strategy
    This section describes the conversion strategy to be used for software.

    31.2.2.3.3.     Data Conversion Strategy
    This section describes the data conversion strategy, data quality assurance, and the data
    conversion controls.

    31.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

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 216 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    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.

    31.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.

    31.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.
    31.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.
    31.2.3.         CONVERSION TASKS
    This section describes the major tasks associated with the conversion, including planning and
    pre-conversion tasks.
    31.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




                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                    1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 217 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


    31.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.
    31.2.3.3.       Major Tasks and Procedures
    This section addresses the major tasks associated with the conversion and the procedures
    associated with those tasks.

    31.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.

    31.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.
    31.2.4.         CONVERSION SCHEDULE
    This 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.
    31.2.5.         SECURITY
    If appropriate for the system to be implemented, provide an overview of the system security
    features and the security during conversion.
    31.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.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                           AVS                                             QPM #
                                                                                                    1
                Quality Management System                             AQS 200-001-WI

                                                                                                Page 218 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                   350


    31.2.5.2.       Security during Conversion
    This section addresses security issues specifically related to the conversion effort.
    31.3. CONVERSION SUPPORT
    This 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.
    31.3.1.         HARDWARE
    This section lists support equipment, including all hardware to be used for the conversion.
    31.3.2.         SOFTWARE
    This 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
    31.3.3.         FACILITIES
    This section identifies the physical facilities and accommodations required during the conversion
    period.
    31.3.4.         MATERIALS
    This section lists support materials.
    31.3.5.         PERSONNEL
    This 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.




                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 219 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    31.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.
    31.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.
    31.4. CONVERSION PLAN OUTLINE
    Cover Page
    Table of Contents
    1.0 Introduction
           1.1 Purpose and Scope
           1.2 Points of Contact
           1.3 Project References
           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 Tasks
                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 220 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


                   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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 221 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350



    32     SYSTEM DESIGN DOCUMENT

    32.1. INTRODUCTION
    32.1.1.         PURPOSE AND SCOPE
    This section provides a brief description of the Systems Design Document's purpose and scope.
    32.1.2.         PROJECT EXECUTIVE SUMMARY
    This 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.
    32.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.
    32.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.
    32.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.
    32.1.3.         DOCUMENT ORGANIZATION
    This section describes the organization of the Systems Design Document.
    32.1.4.         POINTS OF CONTACT
    This 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.
    32.1.5.         PROJECT REFERENCES
    This 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.

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                              QPM #
                                                                                                   1
              Quality Management System                               AQS 200-001-WI

                                                                                             Page 222 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                  350


    32.1.6.        GLOSSARY
    Supply 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.
    32.2. SYSTEM ARCHITECTURE
    In 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.
    32.2.1.        SYSTEM HARDWARE ARCHITECTURE
    In 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.
    32.2.2.        SYSTEM SOFTWARE ARCHITECTURE
    In 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.
    32.2.3.        INTERNAL COMMUNICATIONS ARCHITECTURE
    In 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.
    32.3. FILE AND DATABASE DESIGN
    Interact 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.


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                    Revision
                           AVS                                                  QPM #
                                                                                                        1
                Quality Management System                                  AQS 200-001-WI

                                                                                                   Page 223 of
Title: System Development Lifecycle                                     Date: 2/5/07
                                                                                                       350


    32.3.1.         DATABASE MANAGEMENT SYSTEM FILES
    This 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
    32.3.2.         NON-DATABASE MANAGEMENT SYSTEM FILES
    In 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
    32.4. HUMAN-MACHINE INTERFACE
    This 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.




                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                               AQS 200-001-WI

                                                                                              Page 224 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350


    32.4.1.        INPUTS
    This 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
    32.4.2.        OUTPUTS
    This 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
    32.5. DETAILED DESIGN
    This 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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 225 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


    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.
    32.5.1.        HARDWARE DETAILED DESIGN
    A 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
    32.5.2.        SOFTWARE DETAILED DESIGN
    A 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.

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

                                                                                              Page 226 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350


                  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
    32.5.3.        INTERNAL COMMUNICATIONS DETAILED DESIGN
    If 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
    32.6. EXTERNAL INTERFACES
    External 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.
    32.6.1.        INTERFACE ARCHITECTURE
    In 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.
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                          AVS                                               QPM #
                                                                                                   1
               Quality Management System                               AQS 200-001-WI

                                                                                              Page 227 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    32.6.2.        INTERFACE DETAILED DESIGN
    For 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.
    32.7. SYSTEM INTEGRITY CONTROLS
    Sensitive 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
                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 228 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


    32.8. DESIGN DOCUMENT OUTLINE
    Cover Page
    Table of Contents
    1.0 Introduction
           1.1 Purpose and Scope
           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.4 Points of Contact
           1.5 Project References
           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

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 229 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


    Appendix X - Requirements Traceability Matrix




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 230 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350



    33     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.
    33.1. INTRODUCTION
    This section provides an overview of the information system and includes any additional
    information that may be appropriate.
    33.1.1.         PURPOSE
    This section describes the purpose of the Implementation Plan. Reference the system name
    and identify information about the system to be implemented.
    33.1.2.         SYSTEM OVERVIEW
    This section provides a brief overview of the system to be implemented, including a description
    of the system and its organization.
    33.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.
    33.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.
    33.1.3.         PROJECT REFERENCES
    This 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.
    33.1.4.         GLOSSARY
    Provide 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.




                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                              QPM #
                                                                                                  1
               Quality Management System                              AQS 200-001-WI

                                                                                              Page 231 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                 350


    33.2. MANAGEMENT OVERVIEW
    The subsequent sections provide a brief description of the implementation and major tasks
    involved in this section.
    33.2.1.        DESCRIPTION OF IMPLEMENTATION
    This section provides a brief description of the system and the planned deployment, installation,
    and implementation approach.
    33.2.2.        POINTS OF CONTACT
    In 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.
    33.2.3.        MAJOR TASKS
    This 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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                    Revision
                           AVS                                                 QPM #
                                                                                                       1
                Quality Management System                                  AQS 200-001-WI

                                                                                                Page 232 of
Title: System Development Lifecycle                                   Date: 2/5/07
                                                                                                      350


                           Preparing site facilities for implementation
    33.2.4.         IMPLEMENTATION SCHEDULE
    In 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.
    33.2.5.         SECURITY
    If 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.
    33.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.
    33.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.
    33.3. IMPLEMENTATION SUPPORT
    This 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.
    33.3.1.         HARDWARE, SOFTWARE, FACILITIES, AND MATERIALS
    In this section, list support software, materials, equipment, and facilities required for the
    implementation, if any.
    33.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.




                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                   1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 233 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    33.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.
    33.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.
    33.3.1.4.       Material
    This section provides a list of required support materials, such as magnetic tapes and disk
    packs.
    33.3.2.         PERSONNEL
    This 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.
    33.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.
    33.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.



                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 234 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


                   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).
    33.3.3.         PERFORMANCE MONITORING
    This section describes the performance monitoring tool and techniques and how it will be used
    to help decide if the implementation is successful.
    33.3.4.         CM INTERFACE
    This 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.
    33.4. IMPLEMENTATION REQUIREMENTS BY SITE
    This 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.
    33.4.1.         SITE NAME OR IDENTIFICATION FOR SITE X
    This section provides the name of the specific site or sites to be discussed in the subsequent
    sections.
    33.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.

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 235 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


                   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.
    33.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

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 236 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    33.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.
    33.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.
    33.5. IMPLEMENTATION PLAN OUTLINE
    Cover 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.3 Project References
           1.4 Glossary
    2.0 Management Overview
           2.1 Description of Implementation
           2.2 Points of Contact
           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 Material
                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 237 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


           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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                               QPM #
                                                                                                   1
              Quality Management System                               AQS 200-001-WI

                                                                                             Page 238 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350



    34     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.
    34.1. INTRODUCTION
    This section provides general reference information regarding the Maintenance Manual.
    Whenever appropriate, additional information may be added to this section.
    34.1.1.        PURPOSE
    In this section, describe the purpose of the manual and reference the system name and
    identifying information about the system and its programs.
    34.1.2.        POINTS OF CONTACT
    This 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.
    34.1.3.        PROJECT REFERENCE
    This 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.
    34.1.4.        GLOSSARY
    Provide 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.
    34.2. SYSTEM DESCRIPTION
    The subsequent sections provide an overview of the system to be maintained.
    34.2.1.        SYSTEM APPLICATION
    This 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.


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                   1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 239 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    34.2.2.         SYSTEM ORGANIZATION
    In 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.
    34.2.3.         SECURITY AND THE PRIVACY ACT
    This 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.
    34.2.4.         SYSTEM REQUIREMENTS CROSS-REFERENCE
    This 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.
    34.3. SUPPORT ENVIRONMENT
    This 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.
    34.3.1.         EQUIPMENT ENVIRONMENT
    This section describes the equipment support environment, including the development,
    maintenance, and target host computer environments. Describe telecommunications and facility
    requirements, if any.
    34.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.
    34.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.

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                          AVS                                             QPM #
                                                                                                  1
               Quality Management System                             AQS 200-001-WI

                                                                                              Page 240 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


    34.3.2.        SUPPORT SOFTWARE
    This 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.
    34.3.3.        DATABASE CHARACTERISTICS
    This 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.
    34.3.4.        PERSONNEL
    This 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.
    34.4. SYSTEM MAINTENANCE PROCEDURES
    This section contains information on the procedures necessary for programmers to maintain the
    software.
    34.4.1.        CONVENTIONS
    This 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.
    34.4.2.        VERIFICATION PROCEDURES
    This 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.


                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                 QPM #
                                                                                                    1
              Quality Management System                                AQS 200-001-WI

                                                                                               Page 241 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


    34.4.3.        ERROR CONDITIONS
    This 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.
    34.4.4.        MAINTENANCE SOFTWARE
    This section references any special maintenance software and its supporting documentation
    used to maintain the system.
    34.4.5.        MAINTENANCE PROCEDURE
    This 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.
    34.5. SOFTWARE UNIT MAINTENANCE PROCEDURES
    For 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
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 242 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


    34.6. MAINTENANCE MANUAL OUTLINE
    Cover Page
    Table of Contents
    1.0 Introduction
           1.1 Purpose
           1.2 Points of Contact
           1.3 Project References
           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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                      1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 243 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350



    35     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.
    35.1. GENERAL
    35.1.1.         INTRODUCTION AND PURPOSE
    Describe the introduction and purpose of the Operations Manual, the name of the system to
    which it applies, and the type of computer operation.
    35.1.2.         PROJECT REFERENCES
    List, at a minimum, the User Manual, Maintenance Manual, and other pertinent documentation.
    35.1.3.         GLOSSARY
    List any 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 APPLICATION
    Provide a brief description of the system, including its purpose and uses.
    35.2.2.         SYSTEM ORGANIZATION
    Describe the operation of the system by the use of a chart depicting operations and
    interrelationships.
    35.2.3.         SOFTWARE INVENTORY
    List the software units, to include name, identification, and security considerations. Identify
    software necessary to resume operation of the system in case of emergency.
    35.2.4.         INFORMATION INVENTORY
    Provide information about data files and databases that are produced or referenced by the
    system.
    35.2.4.1.       Resource Inventory
    List all permanent files and databases that are referenced, created, or updated by the system.
    35.2.4.2.       Report Inventory
    List all reports produced by the system. Include report name and the software that generates it.
    35.2.5.         PROCESSING OVERVIEW
    Provide information that is applicable to the processing of the system. Include system
    restrictions, waivers of operational standards, and interfaces with other systems.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 244 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    35.2.6.         COMMUNICATIONS OVERVIEW
    Describe the communications functions and process of the system.
    35.2.7.         SECURITY
    Describe the security considerations associated with the system.
    35.2.8.         PRIVACY ACT WARNING
    Include a Privacy Act warning if the system is covered by the Privacy Act.
    35.3. DESCRIPTION OF RUNS
    35.3.1.         RUN INVENTORY
    List 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.
    35.3.2.         RUN SEQUENCE
    Provide 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
    35.3.3.         DIAGNOSTIC PROCEDURES
    Describe 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.
    35.3.4.         ERROR MESSAGES
    List all error codes and messages, with operator responses as appropriate.
    35.3.5.         RUN DESCRIPTIONS
    Provide detailed information needed to execute system runs. For each run include the
    information discussed in the subsequent sections.
    35.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.



                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                              QPM #
                                                                                                      1
                Quality Management System                              AQS 200-001-WI

                                                                                               Page 245 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350


    35.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.
    35.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
    35.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.
    35.3.5.5.       Restart/Recovery Procedures
    Provide instructions by which the operator can initiate restart or recovery procedures for the run.
    35.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.
    35.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.).
    35.4. OPERATIONS MANUAL OUTLINE
    Cover Page
    Table of Contents
    1.0 General
           1.1 Introduction and Purpose
           1.2 Project References
           1.3 Glossary
    2.0 System Overview
           2.1 System Application
           2.2 System Organization
           2.3 Software Inventory
           2.4 Information Inventory

                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 246 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


                   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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                    1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 247 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350



    36     SYSTEM ADMINISTRATION MANUAL

    A Systems Administration Manual serves the purpose of an Operations Manual in distributed
    (client/server) applications.
    36.1. GENERAL
    36.1.1.         INTRODUCTION AND PURPOSE
    This 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.
    36.1.2.         PROJECT REFERENCES
    This section lists, at a minimum, the User Manual, Maintenance Manual, and other pertinent
    available systems documentation.
    36.1.3.         GLOSSARY
    This section lists all definitions or terms unique to this document or computer operation and
    subject to interpretation by the user of this document.
    36.2. SYSTEM OVERVIEW
    36.2.1.         SYSTEM APPLICATION
    This section provides a brief description of the system, including its purpose and uses.
    36.2.2.         SYSTEM ORGANIZATION
    This section describes the organization of the system by the use of a chart depicting
    components and their interrelationships.
    36.2.3.         INFORMATION INVENTORY
    This section provides information about data files, and the databases that are produced or
    referenced by the system.
    36.2.3.1.       Resource Inventory
    This section lists all permanent files and databases that are referenced, created, or updated by
    the system.
    36.2.3.2.       Report Inventory
    This section lists all reports produced by the system, including each report name and the
    software that generates it.
    36.2.4.         PROCESSING OVERVIEW
    This 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.
    36.2.5.         COMMUNICATIONS OVERVIEW
    This section describes the communications functions and process of the system.
                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 248 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    36.2.6.         SECURITY
    This section describes the security considerations associated with the system.
    36.2.7.         PRIVACY ACT WARNING
    If this system is covered by the Privacy Act, then this section provides the appropriate Privacy
    Act notice and warning.
    36.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.
    36.3.1.         SITE LOCATION(S)
    This is the official address(es) of the site(s).
    36.3.2.         PRIMARY SITE
    For the site(s) designated as primary, this section describes the essential personnel names and
    phone numbers for the automated data processing site contacts.
    36.4. SYSTEMS ADMINISTRATION
    This section introduces the responsibilities of the System Administrator, as discussed in the
    subsequent sections.
    36.4.1.         USER AND GROUP ACCOUNTS
    This section introduces topics related to system users.
    36.4.1.1.       Adding/Deleting Users
    This section describes procedures to create/delete user logins and password accounts.
    36.4.1.2.       Setting User Permissions
    This section describes procedures to give users/restrict access to certain files.
    36.4.1.3.       Adding/Deleting User Groups
    This section contains procedures to create/delete user groups.
    36.4.1.4.       Setting User Roles/Responsibilities
    This section describes the roles that are granted to each group or individual user(s).
    36.4.2.         SERVER ADMINISTRATION
    This section describes procedures to setup servers, including naming conventions and
    standards.
    36.4.2.1.       Creating Directories
    This section describes procedures to create server directories, and a complete description of
    the existing directories.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 249 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    36.4.2.2.       Building Drive Mappings
    This section describes procedures to create server drive mappings, and a complete description
    of the existing drive mappings.
    36.4.3.         SYSTEM BACKUP PROCEDURES
    This section describes procedures for regularly scheduled backups of the entire network,
    including program and data storage, and the creation and storage of backup logs.
    36.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.
    36.4.3.2.       Off-Site Storage Procedures
    This section describes the location, schedule, and procedures for off-site storage.
    36.4.3.3.       Maintaining Backup Log
    This section describes procedures for creating and maintaining backup logs.
    36.4.4.         PRINTER SUPPORT
    This section discusses procedures for installing, operating, and maintaining printers.
    36.4.4.1.       Maintenance
    This section describes maintenance contracts, procedures to include installation and
    configuration of printer drivers, and equipment information.
    36.4.4.2.       Print Jobs
    This section describes procedures to monitor, delete, and prioritize print jobs.
    36.4.5.         SYSTEM MAINTENANCE
    This section discusses procedures for maintaining the file system.
    36.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.
    36.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.
    36.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.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                           AVS                                             QPM #
                                                                                                   1
                Quality Management System                             AQS 200-001-WI

                                                                                               Page 250 of
Title: System Development Lifecycle                                 Date: 2/5/07
                                                                                                  350


    36.4.5.4.       Maintenance Reports
    This section includes procedures to create and update maintenance reports.
    36.4.6.         SECURITY PROCEDURES
    This section describes the process for obtaining identifications (IDs) and passwords. It includes
    information concerning network access and confidentiality requirements.
    36.4.6.1.       Issuing IDs and Passwords
    This section describes procedures for issuing IDs and passwords for operating systems and
    applications.
    36.4.6.2.       License Agreements
    This section describes licensing agreements and procedures for ensuring that all licenses are
    current.
    36.4.7.         NETWORK MAINTENANCE
    This section describes procedures to maintain and monitor the data communications network.
    36.4.7.1.       LAN Design
    This section contains a layout of the network.
    36.4.7.2.       Communications Equipment
    This section contains a layout of the telecommunications equipment.
    36.4.8.         INVENTORY MANAGEMENT
    This section contains a complete hardware and software inventory to include make, model,
    version numbers, and serial numbers.
    36.4.8.1.       Maintaining Hardware and Software Configurations
    This section describes procedures for maintaining the configuration information for the hardware
    and software actually installed.
    36.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.
    36.4.8.3.       Installing or Upgrading Software/Hardware
    This section describes procedures for installing new or upgrading hardware and software.
    36.4.8.4.       Maintaining Lists of Serial Numbers
    This section describes procedures for maintaining all serial number lists required at the site.
    36.4.8.5.       Maintain Property Inventory
    This section describes procedures for maintaining a property inventory at the site.


                             UNCONTROLLED COPY WHEN DOWNLOADED
                Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                          AVS                                               QPM #
                                                                                                    1
               Quality Management System                               AQS 200-001-WI

                                                                                                Page 251 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


    36.4.9.          TRAINING BACKUP ADMINISTRATOR
    This section describes how to train a backup administrator.
    36.4.10.         END-USER SUPPORT--PROCEDURES FOR SUPPORT AND CONTRACT
                     INFORMATION
    This section provides necessary end-user contract information and the procedures for providing
    end-user support.
    36.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.
    36.4.11.         DOCUMENTATION
    This section describes the documentation required of System Administrators as they perform
    system administration.
    36.4.11.1.       Troubleshooting Issues
    This section describes how to conduct and document troubleshooting activities.
    36.4.12.         DATABASE MAINTENANCE
    This section introduces the responsibilities as they relate to the database and software
    application maintenance.
    36.4.12.1.       Database User/Group Access
    Describe who provides database access and the procedures for granting access.
    36.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.
    36.4.12.3.       Setting User Permissions for Database
    Provide the responsible person who sets the permissions for users on the database.
    36.4.12.4.       Adding/Deleting Groups for Database
    Provide the procedures and responsible person for adding/deleting groups of individuals to the
    database.
    36.4.12.5.       Re-indexing Database
    Provide the procedures and responsible person for re-indexing the database after changes have
    been made.
    36.4.12.6.       Packing/Compressing Database
    Provide the procedures and responsible person for packing/compressing the database.



                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                 Revision
                          AVS                                               QPM #
                                                                                                    1
               Quality Management System                               AQS 200-001-WI

                                                                                                Page 252 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


    36.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.
    36.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.
    36.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.
    36.4.13.         APPLICATION MAINTENANCE
    36.4.13.1.       Application User/Group Access
    Describe who provides application access and the procedures for granting access.
    36.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.
    36.4.13.3.       Setting User Application Permissions
    Provide the responsible person who sets the permissions for users of the application.
    36.4.13.4.       Adding/Deleting Application Groups
    Provide the procedures and responsible person for adding/deleting application groups.
    36.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.
    36.4.13.6.       Application Flow Chart
    Provide a flow chart depicting how the information moves from the application to the database.
    36.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.
    36.5. SYSTEMS ADMINISTRATION MANUAL OUTLINE
    Cover Page
    Table of Contents
    1.0 General
           1.1 Introduction and Purpose

                              UNCONTROLLED COPY WHEN DOWNLOADED
                 Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                               Revision
                        AVS                                               QPM #
                                                                                                  1
             Quality Management System                               AQS 200-001-WI

                                                                                              Page 253 of
Title: System Development Lifecycle                                Date: 2/5/07
                                                                                                 350


            1.2 Project References
            1.3 Glossary
    2.0 System Overview
            2.1 System Application
            2.2 System Organization
            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

                            UNCONTROLLED COPY WHEN DOWNLOADED
               Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 254 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


           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

                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                              Revision
                        AVS                                              QPM #
                                                                                                 1
             Quality Management System                              AQS 200-001-WI

                                                                                             Page 255 of
Title: System Development Lifecycle                               Date: 2/5/07
                                                                                                350


                   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




                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                QPM #
                                                                                                   1
              Quality Management System                                AQS 200-001-WI

                                                                                              Page 256 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                  350



    37     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.
    37.1. INTRODUCTION
    This 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.
    37.1.1.        BACKGROUND AND SCOPE
    This 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.
    37.1.2.        POINTS OF CONTACT
    This 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.
    37.1.3.        DOCUMENT ORGANIZATION
    The organization of the Training Plan is described in this section.
    37.1.4.        PROJECT REFERENCES
    This 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.
    37.1.5.        SECURITY AND THE PRIVACY ACT
    If 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


                           UNCONTROLLED COPY WHEN DOWNLOADED
              Check The Master List To Verify That This Is The Correct Revision Before Use
                                                                                                Revision
                         AVS                                                QPM #
                                                                                                    1
              Quality Management System                                AQS 200-001-WI

                                                                                              Page 257 of
Title: System Development Lifecycle                                  Date: 2/5/07
                                                                                                   350


    a notification of the Privacy Act's civil and criminal penalties for unauthorized use and disclosure
    of system data.
    37.1.6.        GLOSSARY
    This 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.
    37.2. REQUIREMENTS TRACEABILITY
    If possible, this section presents a traceability matrix that lists user requirements as documented
    in the FRD and traces how