Aim of Management by cpu96461

VIEWS: 58 PAGES: 21

More Info
									Aeronautical Information Management (AIM)
  Program Planning and Execution Process
              For AIM Operations



                 Submitted by:
                  Brett Brunk
          AIM Architecture and Planning
                    AJR-32

                  May 27, 2009




                        1
 Revision History

Control Number      Revision   Revision       Entered By    Revision Description
                               Date
                               February 14,   Brett Brunk   Updates to governance
                               2009                         process to reflect
                                                            implementation; details
                                                            of process in additional
                                                            appendices.
                               May 27, 2009   Brett Brunk   Process changed from
                                                            “Governance” to “AIM
                                                            Program Planning and
                                                            Execution for
                                                            Operational Programs”.
                                                            Processes described as
                                                            discussed with
                                                            Management Team in
                                                            April 2009 meetings.




                                         2
                                                Table of Contents


     Revision History ........................................................................................................ 2
     Table of Contents ....................................................................................................... 3
     1    Purpose.............................................................................................................. 4
     1    Purpose.............................................................................................................. 4
     2    Background ....................................................................................................... 4
          2.1 History...................................................................................................... 4
          2.2 Mission/Objectives .................................................................................. 4
     2.3 Purpose of Process Changes ............................................................................. 4
          2.4 Using Enterprise Architecture.................................................................. 5
          2.5 Challenges ................................................................................................ 5
     3    Scope of Work .................................................................................................. 5
     4.   Guiding Principles ............................................................................................ 6
     5    Process Description ........................................................................................... 6
          5.1 Process Steps ............................................................................................ 6
          5.2 Roles and Responsibilities ..................................................................... 13
     6    Guidance: External Coordination ................................................................... 15
     7    Meetings .......................................................................................................... 16
     8    References ....................................................................................................... 16
     9    Acronyms ........................................................................................................ 16
     Appendix A .............................................................................................................. 18
     Appendix B .............................................................................................................. 19


                                                         List of Figures

Figure 1: AIM Program Planning and Execution Process (continued) 11
Figure 2: AIM Enterprise Architecture Products 12
Figure 3: Enterprise Architecture Products Required for JRC 13




                                                              3
1      Purpose

This document establishes the processes for Aeronautical Information Management
(AIM) program planning and execution. This process will include the use of Enterprise
Architecture (EA) analysis in AIM system development and maintenance, and in program
governance.

2      Background

2.1    History

The AIM Group within the Federal Aviation Administration (FAA) Airspace and AIM
Directorate is responsible for aeronautical information management systems and services
that collect, quality check, configuration manage and distribute aeronautical information
to internal and external aviation customers. In 2006-2007 the AIM Architecture and
Planning (A&P) staff developed an AIM Vision and Strategy document outlining the
mission, goals and strategies of AIM.

2.2    Mission/Objectives

The mission of the AIM Architecture and Planning Group is to improve the execution of
AIM through strategic planning and architecture of AIM programs and processes.

2.2.1 Objective 1 is to increase the quality, effectiveness, and consistency of AIM
information and services for the benefit of our customers. The strategies to reach this
objective are to:
     Identify, develop, prototype and integrate new technologies into AIM, and
     Coordinate and synchronize AIM programs, policies and activities to harmonize
        across AIM programs and achieve modernization

2.2.2 Objective 2 is to integrate AIM capability improvements into the overall FAA
mission and National Airspace System (NAS) modernization strategy. The strategies to
reach this objective are to:
     Use EA as a tool for developing, promoting and managing a unified AIM
        modernization plan; and
     Strengthen line-of-site connection between FAA goals and AIM initiatives using
        EA tools.

2.3    Purpose of Process Changes

In order to realize the AIM mission and objectives stated above, the AIM group is
attempting to increase its efficiency and effectiveness through business and system-
driven improvements. Business improvements include:
      Moving from a product-centric to a data-centric paradigm
      Moving from aeronautical information services to aeronautical information
        management


                                            4
         Merging static and dynamic information, and
         Introducing processes to ensure data quality.

System improvements include:
    Converging duplicative systems
    Introducing standards – data standards, web service standards, and software
      technology and tool standards, and
    Using digital technologies.

2.4       Using Enterprise Architecture

In 1996, recognizing the importance of information technology for effective government,
the Congress and the President enacted the Information Technology Management Reform
Act (ITMRA) and the Federal Acquisition Reform Act. These two Acts, known as the
Clinger-Cohen Act (CCA), focus on the need for Federal Agencies to improve the way
they select and manage information technology (IT) resources. The CCA states
“information technology architecture, with respect to an executive agency, means an
integrated framework for evolving or maintaining existing information technology and
acquiring new information technology to achieve the agency’s strategic goals and
information resources management goals.”

According to the FAA Acquisition Management System (AMS), Enterprise Architecture
defines the operational and technical framework for all capital assets of the FAA. It
describes the agency’s current and target architectures, as well as the transition strategy
for moving from the current to the target architecture.

Using Enterprise Architecture is required by law; its use is also beneficial. It can provide
very valuable information and processes to help our organization become more efficient
and cost effective. [From NAS Enterprise Archtecture Training to Support AMS
Activities]

2.5       Challenges

Whenever a new process is introduced into an organization, even if everyone realizes that
it will be beneficial to use, there may be a reluctance to change. Such reluctance can be
overcome by open communication, incorporating feedback into the process, and proper
training. AIM has already begun to make progress in process improvement, as witnessed
by the Notice to Airmen (NOTAM) Realignment initiative. The introduction of
Enterprise Architecture analysis is another step in AIM process improvement.

3         Scope of Work

This document describes the processes for program planning and execution within all of
AIM: operational program changes, legacy system updates, new systems and investment
programs.



                                              5
These processes involve the use of Enterprise Architecture and make use of the Guide to
Federal Enterprise Architecture

4.     Guiding Principles

Within AIM, organizational, system and process rationalization is to be an ongoing
activity conducted through investment analysis processes and coordination with the FAA
Enterprise Architecture. [Draft AIM Strategic Plan] Enterprise Architecture
methodology will be used in every phase of the System Life Cycle.

5      Process Description

5.1    Process Steps

The process described herein corresponds to the process flow shown in Figure 1.

For changes to operational systems, the process assumes that:
        There is an existing operational system contractor. The contractor is
          responsible for day-to-day operations and system maintenance and repair
          support.
        The existing operational system contractor has EA experience so they can do
          some of the EA system engineering analysis if requested and include EA
          documentation in their solution implementation activities, and
        The existing operational system contractor has included EA governance in
          their contract standard operating procedures.

These assumptions currently apply to NAS Resources (NASR), Airspace Scheduling and
Management (ASM), and NAS Aeronautical Information Management Enterprise System
(NAIMES). However, it is possible, and is included in the process, that the Management
Team may decide that a new contract is needed, even for changes to operational
programs and legacy systems.

5.1.1 The first step, Identify Mission Needs, is initiated by a sponsor. For a change to
an operational program or a legacy system, the sponsor is usually the Operations
Manager. For a new system, the sponsor could be a member of the Management Team or
the A&P Manager. The sponsor defines the problem that needs solving (what operational
need exists or circumstance has changed), the stakeholders, the timeline and the goals of
the project. The AIM Management Team appoints a Project Lead.

5.1.2 If this change applies to an operational program, at this point, the Operations
Manager, the A&P Manager and the Project Lead, with assistance from the EA team,
perform an impact assessment to determine whether the project needs to follow the
Program Planning and Execution process (including EA System Engineering Analysis) or
not.

Generally a change affects the architecture if:


                                             6
      The change will result in an NAS Change Proposal (NCP) [See Appendix A for
       Configuration Management information.]
      or a Safety Risk Management Document (SRMD)
      or spans multiple parts of the AIM enterprise
      or involve groups outside of AIM
      or an interface is added or removed
      or a system capability, function, technology or data structure is added or removed
      or an operational activity is added or removed

The Management Team determines whether the project must be presented to the NAS
CCB and/or requires a SRMD. The time-frame of the required change must be evaluated:
can a short-term solution suffice until there is time to implement a long-term solution.

A new system or investment program will affect the architecture and need to go through
the Program Planning and Execution process. An investment program will need to
follow the AMS process.

5.1.3 The next step, Develop Concept of Operations, is performed by the Project Lead
and A&P Manager, with the assistance of the EA team. The Concept of Operations
formalizes the mission need by covering:
             Operations (business) issues
             Operational activities to be accomplished
             Stakeholders
             Time frames
             Constraints, and
             Assumptions.

This Concept of Operations can be a separate document or the narrative part of the NAS
EA Framework (NASEAF) Operational Concept View (OV-1) artifact. Appendix B lists
suggested topics to be included in the Concept of Operations. After the Concept of
Operations is developed, it is presented to the Management Team for a “go/no-go”
decision and to decide whether engineering analysis should be performed. For a new
system or investment program, further analysis is required.

5.1.4 The next step, System Engineering Analysis, is also performed by the Project
Lead and A&P Manager, with the assistance of the EA team. They perform:
     Analysis of impact on the AIM enterprise:
           – Impacts to operations and systems
           – Dependencies, and
           – Allocation of operational activities to system functions.
     Gap analysis
     Rough benefit/cost analysis
     Analysis of alternate solutions, and
     Analysis of possible acquisition strategies
 Functional requirements may be developed as part of this analysis.


                                            7
This analysis is performed using EA views. The views used are a set of “AS-IS” views
describing the current system and of “TO-BE” views describing the system based on
planned changes or the new system envisioned. The set of views used in the analysis is
high-lighted in Figure 2. These can be supplemented by operational event trace
descriptions (OV-6c) or other EA products listed in Figure 2, depending on the scope of
the project and the relevancy of the various views to it. These views will be used to
define the work to be performed to upgrade or modify the current system(s). The entire
set of EA views listed in Figure 2 is used to document AIM operations and systems.
Figure 3 lists the EA views required presently for the Joint Resource Council (JRC).

Alternate solutions can depend on the time-frame involved, or merely be different
possible solutions.

The evaluation is documented in a project change proposal.

5.1.5 In the decision step after the System Engineering Analysis, the Program Planning
and Execution Management Team decide what course to take, based on the enterprise
impact assessment and the “TO-BE” strategy, described in the project change proposal.
Their decision is informed by the following questions:
      Is the solution consistent with AIM objectives? Is it part of the strategic AIM
        “TO-BE” EA? Is it part of the AIM Roadmap?
      Is it consistent with AIM business plans? Is there a line-of-sight connection to
        performance activities? Does the change lower Life Cycle costs? Does it provide
        Life Cycle benefits?
      Does the solution cover key enterprise issues?
      Are the operational and system impacts acceptable?
      Is there a critical operational need that would preclude a planned solution?
      Is there an operational solution that moves us towards the preferred approach?

While an investment program must be compliant with AIM plans and strategic
architecture, operational systems should be compliant with the strategic AIM plans and
strategic architecture.

5.1.6 If the decision is made to accept the change proposal, the Program Planning and
Execution activities continue. The Project Lead, the Business Manager, and the
Architecture and Planning Manager, with the assistance of the EA team:
      Evaluate life-cycle costs
      Identify the program or operations funding to be used
      Identify required engineering services
      Allocate the work to an existing contract or determine a new contract is required
      Develop a spend plan
      Generate a statement of work (if needed), and
      Define program checkpoints and dleiverables.




                                            8
If the decision is made not to accept the change proposal, further refinement of the
proposal may be in order, and a reiteration of some steps of the process performed. This
is particularly true of a change proposal for a new system, unless the decision is made not
to proceed with the new system.

At this point, the Program Implementation Lead or the Operations Lead (if the change is
solely an operational change) and the Business Lead are assigned by their respective
managers. The required engineering services, provided by the AIM Technical
Team/development contractor and the EA checkpoints are identified as well.

The solution development and implementation has to be consistent with the outputs of the
Engineering Analysis. The project management goal is to ensure that the proposed
solution supports the “TO-BE” EA. As the project proceeds, lower level detail of the
TO-BE EA artifacts originally created for the System Engineering Analysis, or additional
documenting artifacts, will be needed. The AIM Technical Team / development
contractor is responsible for updating and providing lower level detail in these EA
products and for developing additional EA artifacts, as needed.

The EA Team contributes to the design and development phase of the project as
consultants. Their role in that phase is to provide guidance to project teams on technical
architecture-related issues, the System Engineering Analysis results, the AIM standards
for tools and technologies, and emerging trends in the industry.

During project implementation, AIM monthly Program Planning and Execution meetings
are an opportunity to review the business and technical solution throughout the life cycle.
These meetings do not take the place of program reviews that may be a contractual
requirement the FAA imposes. The goal is to maintain the alignment of the evolving
system with the TO-BE EA to ensure systems are created that meet AIM’s needs. Once
the project is completed, the AIM Program Planning and Execution team will meet again
to ascertain whether the work effort has been completed in accordance with the “TO-BE”
architecture and AIM goals and objectives. At project completion, the “TO-BE” EA
views become the “AS-IS” views, describing the current architecture. The EA products
should be maintained to provide up-to-date documentation for the system and operational
views of the architecture.

The process has a built-in feedback mechanism. The AIM Strategic Plan, the AIM
Roadmap, as well as the appropriate Resource Planning Document (RPD) and Business
Plan will be used to guide the initial stages of a project and to judge the project’s mission
need and concept of operations, requirements and EA views. The EA views received
from the project at completion may be used to adjust the AIM EA and the AIM Strategic
Plan.




                                              9
                                       Mission      Business Plan connection
    Sponsor                             Need        What is the problem?
                                                    Background                      Review
                                                    Time lines and goals
                                                    (Management Team designates project lead)


  Project Lead                      Impact          Need to follow Program Planning
                                                    & Execution Process?
                                  Assessment
                                                    Time-frame restraints?            Review
  Architecture &
Planning Manager


 A&P Manager
                                       Decision

  Project Lead


  Project Lead                        Concept of    Business plan connection
                                                    What will be accomplished?
                                         Ops
                                                    Operational concept for the future Review
 A&P Manager                                        Background and current process
                                                    Stakeholders
                                                    Constraints and assumptions



   Management
                                         Decision
      Team

   A&P Manager

   Project Lead


 A&P Manager                            System       “AS-IS” EA
                                      Engineering    “To Be” EA
                                       Analysis      Operational and System Impacts
                                                                                    Review
  Project Lead                                       Dependencies
                                                     Gaps/Analysis
                                                     Allocation of operational
                                                     activities to system functions
                                                     Rough benefit/costs
                                                     Alternative solutions
   Management                            Decision
      Team


          Figure 1: AIM Program Planning and Execution Process




                                 10
A&P Manager                           Spend     Spending projections
                                      Plan /    Level of effort estimates
                                      SOW       Collaboration of SOW development
 Project Lead                                   AMS process                      Review

Business Mgr
                                      Design    Contract deliverable reviews
   Program                            Develop   Verification of solution consistency with EA
Technical Team                         Test
                                      Deliver   Solution implementation



   Figure 1: AIM Program Planning and Execution Process (continued)




                                 11
                                                         Applicability of Architecture Products

 Product ID                           Title                  “As Is”               “To Be”

    AV-1      Overview and Summary Information                 Yes                   Yes

    AV-2      Integrated dictionary                            Yes                   Yes

              High-level operational concept
    OV-1
              diagram
                                                              Yes                    Yes


              Operational Node Connectivity
    OV-2
              Description
                                                              Yes                    Yes


              Operational Information Exchange
    OV-3
              Matrix
                                                              Yes                    Yes

    OV-4      Organizational relationship diagram              Yes                   Yes

    OV-5      Operational Activity Model                      Yes                    Yes

    OV-7      Logical Data Model                               Yes                   Yes

    SV-1      Systems Interface Description                   Yes                    Yes

    SV-2      Systems Communications Description               Yes                   Yes

    SV-4      Systems Data Flow Diagram                       Yes                    Yes

              Operational Activity to Systems
    SV-5
              Function Traceability Matrix
                                                              Yes                    Yes


    SV-6      Systems Data Exchange Matrix                    Yes                    Yes

    SV-7      System Performance Matrix                                              Yes

    TV-1      Technical Standards Profile                                            Yes


Note: All products with 2-letter designators are standard NAS EA products. Product definitions
and standards can be found on the NAS EA web site.



                        Figure 2: AIM Enterprise Architecture Products




                                                    12
    Product ID                                               Title

      AV-1       Overview and Summary Information


      AV-2       Integrated dictionary



      OV-1       High-level operational concept diagram




      OV-2       Operational Node Connectivity Description




      OV-3       Operational Information Exchange Matrix


      OV-5       Operational Activity Model


      OV-7       Logical Data Model


      SV-1       Systems Interface Description


      SV-2       Systems Communications Description


      SV-4       Systems Data Flow Diagram


      SV-5       Operational Activity to Systems Function Traceability Matrix


      SV-6       Systems Data Exchange Matrix


     SV-10c      Systems Event - Trace Description



                 Figure 3: Enterprise Architecture Products Required for JRC

5.2       Roles and Responsibilities1

The roles and responsibilities for Program Planning and Execution Process for AIM
Operations are delegated across the four main groups/individuals. These include the
AIM Management Team, the Project Lead, the EA Team, and the AIM Program
Technical Team.




1
 The roles and responsibilities described here are only pertinent to the AIM Program Planning and
Execution. Each group or individual described has other responsibilities related to other activities.


                                                     13
5.2.1   AIM Management Team

The roles and responsibilities of the AIM Management Team, including those of the
Architecture and Planning Manager, Project Lead, and Business Manager are:

        a. Sponsor new change proposal review process by identifying mission need
        b. Determine (for an operational program) whether the project requires the
           Program Planning and Execution process (with Project Lead, Architecture and
           Planning Manager, and EA Team if needed).
        c. Determine which projects should be presented to NAS Change Control Board
           (CCB) and which need a Safety Risk Management Document.
        d. Determine Project Lead, Program Lead, and Operations Lead.
        e. Analyze project change proposals as part of the project review decision steps.
           The project reviews will occur when significant change is contemplated, at
           logical milestones in the Program Planning and Execution process, or at key
           decision points in the System Life Cycle. Reviews may also occur
           periodically as part of the budget cycle.
               i. Verify that the project is worth pursuing, whether the project satisfies
                        the goals defined for AIM.
               ii. Determine how it fits into the Spend Plan, the Roadmap and the
                        schedule.
               iii. Determine what performance objectives the project supports.
               iv. Determine where the project or product fits into the larger AIM
                    Architecture and the NAS Architecture, how the project fits into
                    overall AIM planning goals and objectives, and whether the proposed
                    placement is best-suited for the overall efficiency of the AIM system.
        f. Decide whether or not to approve spending on the project change proposal. If
           the review does not result in approval to proceed with the project, more
           preliminary work may be required and another review meeting held.
        g. Determine lifecycle costs, identify funding, identify required engineering
               services, allocate project to new or existing contract, develop SOW, and
               determine program checkpoints.
        h. Ensure new acquisition follows the FAA AMS process.

5.2.3 Project Lead

The role and responsibilities of the Project Lead are:

        a. Determine whether the project requires the Program Planning and Execution
           process (with Operations Manager, Architecture and Planning Manager, and
           EA Team).
        b. Generate the Concept of Operations and perform impact assessment.
        c. Perform system engineering analysis, resulting in the change proposal.
        d. Present change proposals.
        e. Together with the Business Manager, Architecture and Planning Manager, and
           EA Team, determine lifecycle costs, identify funding, identify required



                                             14
           engineering services, allocate project to new or existing contract, develop
           SOW, and determine program checkpoints.

5.2.6 EA Team

The role and responsibilities of the AIM EA team are:

       a. Assist in the impact assessment and in determining whether a project change
          needs to use the Program Planning and Execution process (together with
          Architecture and Planning Manager and Project Lead).
       b. Assist in the generation of the Concept of Operations by thorough review.
       c. Develop EA Product set and assist in performing system engineering analysis,
          resulting in the change proposal. [The Program Technical Team may be asked
          to help with this.]
       d. Together with the Project Lead, Architecture and Planning Manager, and
          Business Manager, determine lifecycle costs, identify funding, identify
          required engineering services, allocate project to new or existing contract,
          develop SOW, and determine program checkpoints.
       e. Act as a consultant providing guidance to project teams on technical
          architecture-related issues, the System Engineering Analysis results, the AIM
          standards for tools and technologies, and emerging trends in the industry.
       f. Provide stewardship of all EA products.
       g. Ensure that new System or Operational changes get reflected and maintained
          in the EA products, once approval is granted.

5.2.7 AIM Program Technical Team

The role and responsibilities of the AIM Program Technical team are:

       a. Produce “AS-IS” and “TO-BE” EA products for the AIM Program Planning
          and Execution process change proposals as requested by Project Lead.
       b. Provide engineering services to design, develop, test and deliver the project
          changes, under the direction of the Program Lead, if project change proposal
          is approved.
       c. Reflect and maintain changes in the EA products and produce more detailed
          “TO-BE” EA products or additional EA products during project execution.

The Program Lead oversees the work of the AIM Program Technical Team.

6      Guidance: External Coordination

    AIM EA must coordinate with organizations that:
      Use the Aeronautical Information that AIM provides or
      Provide data that is used by AIM.




                                           15
7       Meetings

        The AIM Program Planning and Execution Management Team will meet
         monthly to make go/no-go decisions (or more frequently if decisions need
         immediate resolution) and monitor project implementation.
        AIM Program Technical Team meetings will be held quarterly as an AIM group
         “All Hands” to ensure cohesiveness among development and support
         contractors.
        The EA Team will meet weekly to discuss current EA efforts as well as plans
         for future EA development. The results of EA product review, system
         engineering analysis, and architecture impact will also be discussed at the EA
         Team meeting.

        These meetings may be held back-to-back to facilitate scheduling.

8       References

        1. NAS Enterprise Archtecture Training to Support AMS Activities (FAA
           64000001)

        2. NAS EA web site: http://nas-architecture.faa.gov/nas/home.cfm

        3. NAS EA reference documents web site:
        4. http://nas-architecture.faa.gov/nas/reference/nasea_refdocs.cfm

        5. Chief Information Officer Council, A Practical Guide to Federal Enterprise
           Architecture, Version 1.0, February 2001

9       Acronyms

           AIM    Aeronautical Information Management
           AMS    Acquisition Management System
           A&P    Architecture and Planning
           ASM    Airspace Scheduling and Management
           AV     All View
           CCA    Clinger-Cohen Act
           CCB    Configuration Control Board
           EA     Enterprise Architecture
           FAA    Federal Aviation Administration
           ITMRA Information Technology Management Reform Act
           JRC    Joint Resource Council
           NAIMES NAS Aeronautical Information Management Enterprise System
           NAS    National Airspace System
           NASR   National Airspace System Resources
           NOTAMS Notices to Airmen System
           OV     Operational View


                                           16
RPD   Resource Planning Document
SV    Systems View
TV    Technical Standards View




                        17
                               Appendix A
                 Configuration Management (CM) Information

The AIM Program Planning and Execution Management Team determines what
projects should be presented to NAS CCB after its own review process.

1. The NAS doesn’t own any projects (i.e. systems).

2. The NAS CCB has purview for following only
      a. NAS Requirement (NAS-SR-1000, NAS-SS-1000 & NAS-DD-1000)
      b. NAS Technical Architecture
      c. Final Requirements Documents
      d. Interfaces of Non-NAS Equipment and Prototypes to NAS Equipment
      e. NAS-level Interface Requirements Documents (IRD)
      f. Interface Control Documents (when there is no approved parent IRD)
      g. Non-assigned NAS Systems and Configuration Items
      h. Standards

3. CM/CCB control for any projects approved by the AIM Program Planning and
   Execution Management Team would be under the purview of AIM unless it fits
   the above criteria for the NAS CCB.




                                      18
                                    Appendix B

                            CONCEPT OF OPERATIONS
                                Table of Contents

1. Introduction - A space for background, terms/definitions, and other important
   information required for the reader to understand the ConOps.

   1.1. Operational Use – A short summary of the operations the new project will
        facilitate and the interested parties (users). This should not be a detailed
        explanation, but an introduction to the “what” and “who.”

   1.2. System Overview – A short summary of the proposed system and its associated
        system functions. Again, this should not be a detailed explanation, but an
        introduction to the system being proposed.

   1.3. Document Overview – A short explanation of what will be covered in each
        section of the ConOps. Each section should be explained in 1-3 sentences.

   1.4. References – A list of any documents cited or discussed within the ConOps
        document.

2. Operational Need – The beginning of this section should be a re-statement of the
   Mission Needs Statement. In fact, a copy and paste of this statement into this section
   is a likely practice.

   2.1. Current Environment – A detailed explanation of the current or AS-IS
        operation(s) and system(s). Information that would be useful: all parties
        involved in operation, high level operational activities, and all information/data
        being passed and its origin. This section should only explain the AS-IS operation,
        it should not attempt to analyze why the AS-IS is operationally inadequate.
        Although this section is not an AS-IS system design description, the current
        operational environment needs to be discussed alongside the relevant systems
        that it employs.

   2.2. Capability Shortfalls – A detailed explanation of how the AS-IS operation is
        inadequate. This may include details about data (format, source, fidelity, etc.),
        system design and function, operational shortcomings, new AIM standards that
        are not being met (such as TV-1 technology standards), duplicative efforts,
        and/or new required capabilities not provided by the AS-IS project (and where
        the requirements come from).

3. Project Justification




                                           19
   3.1. Description of Desired Change – A list of specific changes that will be
        implemented by the proposed project. This section should not explain the future
        or TO-BE project in detail, but instead identify all capability shortfalls from
        section 2.2 and the extent to which they will be solved by the TO-BE project.

   3.2. Potential Benefits of New or Modified project – An explanation of what
        benefit each change mentioned in section 3.1 will provide. This may include
        things like improved operational efficiency, data standardization, improved
        safety, etc. Again, there should not be an effort to detail the TO-BE project, but
        simply identify the value the TO-BE project will provide to AIM and to the FAA.

4. Operational Description

   4.1. Project Operations – A detailed explanation of the operational aspects of the
        TO-BE project. This should include a description of all operational activities,
        how users and other involved parties interact, and what types of information are
        passed during these interactions. For service oriented architecture
        considerations, a list of services provided may also be included in this section.

   4.2. Scenarios – A section to discuss use cases and/or event timelines for the TO-BE
        project.

5. System Description

   5.1. System – A detailed explanation of what the TO-BE system needs in order to
        support the operations described in section 4.1. The description might include
        what external systems interface with the new system, considerations based on
        TV-1 standards, and a list of high level system components (such as data
        repository, identity manager, business rules engine, etc.). This section, however,
        should refrain from detailing system solutions such as identifying software
        products, database type, or hardware locations.

   5.2. Functional Description – A detailed explanation of the high level system
        functions supporting the operational activities listed in section 4.1. A connection
        between the system components listed in section 5.1 and the system functions
        listed in this section is important.

6. Assumptions, Constraints, and Dependencies

   6.1. Organizational – A discussion of all organizational assumptions, constraints,
        and dependencies related to the TO-BE project. These might include details
        related to personnel requirements and involvement with the FAA Acquisition
        Management System and Safety Risk Management process. A list of documents
        that will require modification upon completion of the TO-BE project may also be
        discussed here. Such documents include FAA orders, advisory circulars, the
        Code of Federal Regulations, letters of agreement, etc.



                                            20
   6.2. Operational – A discussion of all operational assumptions, constraints, and
        dependencies. This discussion may include the dependencies on other projects
        for data, assumptions about when other TO-BE systems will be completed, and
        constraints based on AIM technical standards.

   6.3. User – A discussion of all user-based assumptions, constraints, and
        dependencies. These may include the assumption of certain qualifications for
        users, or discussions of user training for the TO-BE project.

   6.4. Other – All other assumptions, constraints, and dependencies not discussed in
        sections 6.1-6.3 go into this section.

APPENDIX A – Definitions and Glossary




                                          21
                                  21

								
To top