IVV PROJECT EXECUTION PLAN

Document Sample
IVV PROJECT EXECUTION PLAN Powered By Docstoc
					                                                                        T2103
                                                                        Revision: Basic
                                   IPEP Template                        Effective Date:
    Independent                                                         December 18,
   Verification &                                                       2008
Validation Program

              DOWNLOADED AND/OR HARD COPY UNCONTROLLED
                 Verify that this is the correct version before use.

                 APPROVAL SIGNATURES                                           DATE
Gregory Blaney (original signature on IMS Representative                12/18/2008
file)



                               REVISION HISTORY
Revision   Description of Change           Author                       Effective Date
Basic      Initial Release                 Leigh Gatto                  12/18/2008



                           REFERENCE DOCUMENTS
Document Number                    Document Title
IVV QM                             IV&V Quality Manual
IVV 09-4                           Project Management




                         CHECK THE MASTER LIST at http://ims.ivv.nasa.gov/
                     VERIFY THAT THIS IS THE CORRECT REVISION BEFORE USE

                                          Page 1 of 38
                                                                             T2103
                                                                             Revision: Basic
                                       IPEP Template                         Effective Date:
     Independent                                                             December 18,
    Verification &                                                           2008
 Validation Program

IV&V Project Execution Plan (IPEP) Structure

The IPEP is an agreement between the NASA IV&V Project Manager (NPM) and the NASA
IV&V Program Manager (NASA IV&V Program Director) regarding the planned work,
schedule and resources required to execute the IV&V project. It serves as the operational
document that will be provided to the named IV&V Project to establish a mutual
understanding of the NASA IV&V Program’s efforts. Additionally, the IPEP may be tailored
as necessary by the Mission Directorate Lead (MDL) to fulfill the needs of the Mission
Directorate or a specific IV&V Project.

The IPEP is divided into two major parts: the body of the document, and the appendices.
The body includes plans, schedules, cost estimates, resources, roles and responsibilities,
lines of communication, and reports (deliverables) to establish a formal mutual agreement
as necessary to execute the project. The appendices include specific information related to
the IV&V Programmatic Based Risk Assessment (PBRA) process, IV&V Coverage Diagram
Data, and an acronym list.

Purpose of the IPEP Template

The IPEP Template is designed to provide the following:

   1. A standard outline and format for IPEPs such that reviewers, approvers, and users
      of the document know where to find information
   2. Standard text that is used in all or most IPEPs
   3. Differentiation of standardized text and formatting from tailored text and formatting.
      This speeds up the NASA IV&V Program review and approval process because only
      differences from standard text need to be scrutinized.
   4. Guidance and best practices that provide those who generate or update IPEPs with
      tailoring guidance and section content guidance.

IPEP Template Conventions

Different styles of text are used in this template:

   1. <Text included in angle brackets>

       This text represents Project-specific information to be provided. Examples are
       <Project name> for the name of the Project, and <purpose> for the purpose of the

                             CHECK THE MASTER LIST at http://ims.ivv.nasa.gov/
                         VERIFY THAT THIS IS THE CORRECT REVISION BEFORE USE

                                              Page 2 of 38
                                                                             T2103
                                                                             Revision: Basic
                                       IPEP Template                         Effective Date:
    Independent                                                              December 18,
   Verification &                                                            2008
Validation Program

      Project.

   2. {Italic text in braces}

      This text is guiding or explanatory in nature. It will include tailoring guidance and
      descriptions of the kinds of information to be included in each section. Therefore, it
      should not be included in the IPEP. Remove this text before submitting the IPEP for
      review/approval.


   3. Normal Text

      Text that appears normal (i.e., not highlighted or italicized) is intended to be common
      among all projects. This is standard text that should be copied verbatim into the
      IPEP, unless Project-specific information should be inserted. If you think that the
      text is not accurate for your project, you may propose a change and provide
      rationale to those who review and approve the document.

   4. Highlighted Text

      Text highlighted in yellow is an example. The examples may not be perfect in every
      detail. Insert text appropriate for the project.

   5. Red Italic Text

      Text in red italics is intended to be a heads-up and guidance regarding section
      content, content format, possible sources and locations of information and
      suggestions to help you fill in the section for your project. Remove this text before
      submitting your IPEP for review/approval.

The author will need to number the tables in the IPEP. The author will also list and define
acronyms used in the IPEP in Appendix E, and update the table of contents after making
changes to the IPEP.

Regarding version numbering, all draft versions will have a version number of #.X; the first
NASA IV&V Program-approved version will be #.0. Subsequent versions will have a
version number of #.X. As an example of document versioning, the third draft should be
version number 0.3; the first approved version will be 1.0.

                             CHECK THE MASTER LIST at http://ims.ivv.nasa.gov/
                         VERIFY THAT THIS IS THE CORRECT REVISION BEFORE USE

                                              Page 3 of 38
                                                                 T2103
                                                                 Revision: Basic
                                 IPEP Template                   Effective Date:
  Independent                                                    Month DD, 2007
  Verification &
Validation Facility




                           {Page intentionally left blank.

                      Template begins on the following page.}




                    CHECK THE MASTER LIST at http://ims.ivv.nasa.gov
                VERIFY THAT THIS IS THE CORRECT REVISION BEFORE USE

                                       4 of 38
                                 IV&V PROJECT EXECUTION PLAN




                  <enter Project name>
      Independent Verification and Validation (IV&V)
                  Project Execution Plan
                     Fiscal Year 2009




<Project name>                                           Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                               5
                                 IV&V PROJECT EXECUTION PLAN


DOCUMENT COORDINATION and APPROVALS
This is Version 1.0 of the <enter Project name> Independent Verification and Validation (IV&V)
Project Execution Plan (IPEP).

The IPEP is a configuration managed document. Changes will only be issued as complete
replacement. Recipients should remove superseded versions from circulation. This document is
authorized for use/release once all signatures have been obtained.


PREPARED:                                                               DATE:___/___/___
<enter PL Name>, NASA IV&V Project Lead


COORDINATED:                                                            DATE:___/___/___
Donna Ozburn, NASA IV&V Chief of Resource Management Office


COORDINATED:                                                            DATE:___/___/___
Marcus Fisher, NASA IV&V Chief Engineer


COORDINATED:                                                            DATE:___/___/___
Christina Moats, NASA IV&V Chief of Plans and Programs


APPROVED:                                                               DATE:___/___/___
<MDL Name>, NASA IV&V <enter Mission Directorate Name> Lead


APPROVED:                                                               DATE:___/___/___
Leigh Gatto, NASA IV&V Chief Integration Officer


CONCURRENCE:                                                       DATE:___/___/___
<enter Development Project Rep Name>, <Project> IV&V Point of Contact

APPROVED:                                                               DATE:___/___/___
Dr. Dale Scott Caffall, Director, NASA IV&V Program




<Project name>                                                  Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                6
                                          IV&V PROJECT EXECUTION PLAN


                                                            Table of Contents

1.    Introduction................................................................................................................................. 8
   a. Document Purpose .................................................................................................................. 8
   b. Intended Audience .................................................................................................................. 8
   c. Project Description ................................................................................................................. 8
   d. IV&V Goals and Objectives .................................................................................................. 9
   e. IV&V Scope/Coverage ......................................................................................................... 10
   f. Project Milestones ................................................................................................................. 11
   g. Reference Documentation .................................................................................................... 11
2. Modeling Plan ........................................................................................................................... 13
   a. Methodology........................................................................................................................... 13
   b. Products .................................................................................................................................. 13
   c. Model Review......................................................................................................................... 14
   d. Dependencies .......................................................................................................................... 14
3. Validation Plan ......................................................................................................................... 15
   a. Methodology........................................................................................................................... 15
   b. Products .................................................................................................................................. 17
   c. Dependencies .......................................................................................................................... 18
4. Verification Plan ....................................................................................................................... 19
   a. Methodology........................................................................................................................... 19
   b. Products .................................................................................................................................. 20
   c. Dependencies .......................................................................................................................... 20
5. Schedule Plan ............................................................................................................................ 22
6. Resource Plan and Funding Profile ....................................................................................... 23
   a. IV&V Services ....................................................................................................................... 23
   (1)      Project Lead ................................................................................................................... 23
   (2)      Lead Engineer ................................................................................................................ 23
   b. Travel ...................................................................................................................................... 24
   (1)    IV&V Services.................................................................................................................... 24
7. Management Plan ..................................................................................................................... 25
   a. Roles and Responsibilities .................................................................................................... 25
8. Risk Management Plan ............................................................................................................... 29
Appendix A: Out-year Planning and Profile ............................................................................... 30
   a. IV&V Goals/Objectives ....................................................................................................... 30
   b. Funding Profile ..................................................................................................................... 30
Appendix B: IV&V Portfolio Risk Based Assessment (PBRA) Results.................................. 32
Appendix C: IV&V Coverage ......................................................................................................... 34
Appendix D: Financial Baseline .................................................................................................... 37
   a. Total Project Costs ................................................................................................................ 37
   b. Costs (by month and total)................................................................................................... 37
Appendix E: Acronyms................................................................................................................... 38




<Project name>                                                                                        Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                                             7
                                 IV&V PROJECT EXECUTION PLAN


1.           Introduction

    a.           Document Purpose
This IPEP is an agreement between the NASA IV&V Project Lead (PL) and the IV&V Program
Manager regarding the planned work, schedule and resources required to execute the IV&V
project. The IPEP serves as the operational document for the <enter Project name> IV&V
project. It is prepared, maintained, and utilized by the PL, Lead Engineer (LE), and IV&V Team
to support the delivery of the agreed project deliverables. Although the focus of this IPEP is for
the year of execution, it also contains information regarding IV&V support (at a high level) for
the entire lifecycle (see Appendix A for out-year planning data).

This IPEP is the responsibility of the PL. The PL coordinates the creation and maintenance of
this document with affected individuals and organizations, including but not limited to: IV&V
Product Line Leads, IV&V contractor project/program management, the IV&V Mission
Directorate Lead (MDL), the IV&V Chief of Resource Management Office (RMO), the IV&V
Chief Engineer and the IV&V Chief of Plans and Programs.

     b.           Intended Audience


The intended audience of this document includes the IV&V Program Manager, IV&V Services
Management, IV&V Program RMO, IV&V Engineering Services and IV&V Product Lines
within the IV&V Program. In addition, the IV&V Program seeks <Project name> Project
concurrence with the IV&V approach and activities described in this IPEP. As such, this IPEP
will be shared with customers and stakeholders of the <Project name> IV&V efforts including
but not limited to <Project name> Project Management, <Project name> IV&V Point of Contacts
(POCs) and <Project name> Safety and Mission Assurance (SMA) representatives.

     c.           Project Description

This section should provide a very high-level overview of the Project, the goals/objectives of the
development project, including identifying the responsible Center and development
contractor(s). References for additional information may be listed (project documentation).


The <Project name> is a NASA <enter NASA center affiliation> mission managed by <……>
Directorate. Specific mission goals for the <Project name> are:

The mission success criteria for the <Project name> are below:

The <Project name> will be launched from/on…….. It will be placed in an elliptical orbit about
the semi-stable second Lagrange point (L2). The <enter Project name> mission is planned for a
minimum of five years’ duration.

The JWST system is depicted below in Figure 1-1. The JWST system comprises ……
<Project name>                                                     Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                   8
                                 IV&V PROJECT EXECUTION PLAN




                                       Figure 1-1: JWST System

NASA GSFC Code 443 is responsible for overall Project/Mission Management of the JWST as
well as provision of the ISIM. ESA is providing the NIRSpec Instrument, MIRI Optics
Assembly, and the Ariane Launch Vehicle. The CSA is providing the FGS Instrument. Other
NASA Centers and laboratories are supporting the development of the JWST, these include but
are not limited to Jet Propulsion Laboratory (JPL) providing management and development
support for the MIRI.

The prime contractor responsible for building the Observatory is Northrop Grumman Space
Technologies (NGST). Ball Aerospace serves as a subcontractor to NGST. Other industry
and/or institutional representatives supporting the development of JWST include Lockheed
Martin and the University of Arizona, who are responsible for the management and development
of the NIRCam instrument, and the Space Telescope Science Institute (STSci), which is
responsible for management and development of components of the Ground Segment, including
the S&OC.

Additional information with regard to the JWST can be found at the JWST Project’s web site
located at:    http://www.jwst.nasa.gov/index.html

    d.            IV&V Goals and Objectives

The <Project name> IV&V efforts will conduct model-based verification and validation analyses
to acquire a confidence level of the <Project name> system/software in terms of three
questions/perspectives: (1) Does the system/software do what it is supposed to do? (2) Does the
system/software not do what it is not supposed to do? (3) What does the system/software do
under adverse conditions? This confidence level will be gained over time and will vary
depending upon the development lifecycle phase.
<Project name>                                                   Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                   9
                                 IV&V PROJECT EXECUTION PLAN




Objectives for the IV&V efforts for the applicable execution year shall be identified below. The
list of objectives for the project should be success-oriented statements (i.e., what you ultimately
hope to achieve during the FY) and not just a list of the tasks that the IV&V Team will be
performing. This list of objectives should be consistent with the scope and schedule of the FY09
IV&V tasking.

For FY09, the <Project name> IV&V team has established the following IV&V objectives:
    • (sample objective) Develop a System Reference Model (SRM) that describes the goals of
      the system, what the system software must do to achieve these goals, and the operational
      environment in which the system software must function
    • (sample objective) Obtain a set of validated requirements to assure that the right
      behaviors have been defined and that the behaviors are of high quality
          – Objective for FY09 is to:
                 • Validate L2 system requirements
                 • Validate L3 flight system requirements
                 • Validate L4 (subsystem) requirements for maneuver and fault protection
                     related behaviors
    • (sample objective) Identify areas of risk within the system to serve as a basis for focusing
      IV&V efforts
     (sample objective) Establish initial confidence data points regarding the system and
      software architecture

    e.            IV&V Scope/Coverage

Describe, either in text alone OR in text and additional graphical format, the coverage of the
IV&V efforts on the development project. It is important in this section to identify those
behaviors/capabilities that are not “usually” within the scope of IV&V, but are in this case AND
the converse, those areas that *are* usually within the scope of IV&V, but are not in this case.
Rationale for in scope/out of scope decisions should be included. Note: It is recommended that
each project communicate the IV&V scope in terms of behavior versus functional areas of the
system. This will help ensure that we are consistently communicating the coverage of the system
to all stakeholders (IBD, Mission Directorates, Projects, etc.).



All software that supports the mission in any way—including but not limited to flight software,
ground software, mission systems software, and instrument software—is initially considered for
IV&V. In order to optimize the allocation of IV&V resources across the IV&V Program as well
as within a particular IV&V Project, the IV&V Program employs a Portfolio Based Risk
Assessment (PBRA) process. The PBRA process evaluates the capabilities of the system, which
are aligned with and support the development Project’s goals and objectives. Specifically, the
PBRA process assesses these capabilities in terms of impact of a limitation (defect) and
<Project name>                                                      Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                   10
                                 IV&V PROJECT EXECUTION PLAN


likelihood of a limitation. The result of this assessment is an overall rating for each capability
for that mission that can be used to prioritize the IV&V efforts across the IV&V Program as well
as within a particular IV&V Project. For additional information on the PBRA process and
associated results for the <enter Project name> Project, see Appendix B of this plan. (Note:
Modify this sentence to reflect whether your Project does not have PBRA results, which
primarily apply to new projects.)




In addition to the PBRA process and associated results, the IV&V Program strives to identify
IV&V coverage of the mission using a use case diagram. The use case diagram depicts those
capabilities in a graphical format, such that the high level behaviors of the system, the presence
of safety and mission critical software within those behaviors, and the planned IV&V coverage
for those behaviors are portrayed. For additional information on IV&V coverage and associated
results for the <Project name> Project, see Appendix C of this plan.




    f.            Project Milestones

List, in text or tabular format, key development project milestones. Depending on the
development project, this may include OpsCon Review, SRR, PDR, CDR, MRR, ORR, etc. Make
sure to include the launch date.

The IV&V effort is intended to be in-phase with the development efforts. As such, as much as
possible, IV&V strives to tie IV&V products and analysis results to development milestone
reviews. The currently known development project milestones are captured in Table 1 -1.
                                 Table 1-1: <Project name> Key Milestones

              Key Milestone                          Current Planned Date
              <Project name> Launch                  0X/20XX
              Review Date 1
              Review Date 2




   g.           Reference Documentation
The IV&V Reference documents should be standard across all IV&V Projects. The Additional
Relevant Documentation table is filled in at the PL’s discretion. When thinking about what you
want to include in the Additional Relevant Documentation table, we suggest that you keep it
high-level (not down to tasks or low-level artifacts) and try to think about what you’d tell a new
personnel assigned to your project to go look at to get up to speed quickly.
<Project name>                                                        Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                     11
                                   IV&V PROJECT EXECUTION PLAN



The following documents are referenced in this IPEP or were used in its development and/or
execution:
                                   Table 1-2: IV&V Reference Documentation

Document               Title                                        Link or Date
NPD 2820.1C            NASA Software Policy                         NPD_2820
IVV 09-1               Independent Verification and Validation      IVV_09-1
IVV 09-4               Project Management                           IVV_09-4
IVV 09-9               Risk Management                              IVV_09-9

S3001                  Guidelines for Risk Management               S3001




                                  Table 1-3: Additional Relevant Documentation

Document                  Title                                             Link or Date




<Project name>                                                          Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                         12
                                 IV&V PROJECT EXECUTION PLAN


2.           Modeling Plan

This section should describe what modeling has been performed/completed to date and what
modeling is being planned for in the execution year. This section should provide some rationale
for the modeling efforts for the execution year. Example rationale includes supporting specific
validation and/or verification-related activities, etc. This section should also list the specific
products (if any) that will be produced by the SRM Product Line during the execution year.

     a.           Methodology

This section should provide a very high-level description of the modeling approach. Focus on
what’s going to be done versus the “hows”. The “hows” will be covered in the Modeling
Product Line Execution Plan.

     As the basic system reference model is completed, the FY09 modeling efforts will focus on
     developing the extended reference model for various behaviors of the <Project name>.
     Specific threads that will be elaborated include TBP. These models will provide additional
     views/insight to support the validation and verification efforts described in the following
     sections.
     The modeling efforts will develop a System Reference Model that describes the goals of the
     system, what the system must do to achieve these goals, and the operational environment in
     which the system must operate. The model will depict/represent the desired system behaviors
     in terms of three perspectives: (1) what the system/software is supposed to do, (2) what the
     system/software is not supposed to do, and (3) what the system/software is supposed to do
     under adverse conditions.

     Specific modeling tasks to be performed are listed below:

         WBS 1.1 Identify System Goals and Operational Environment

         WBS 1.2 Develop System-Level Behavioral Model

         WBS 1.3 Elaborate Behaviors: If specific behaviors to be elaborated are known, identify
          them here.

         WBS 1.4 Develop System Architectural Model

         WBS 1.5 Develop Software Architectural Model

     b.           Products

This section should provide a listing of all the modeling products that the Modeling Product Line
will produce for the IV&V efforts.

This section provides a listing of the modeling products that the Modeling Product Line will
produce for the IV&V efforts.
<Project name>                                                     Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                   13
                                 IV&V PROJECT EXECUTION PLAN


                               Table 2-1: Additional Relevant Documentation

Product Name              Description                                   Proposed Due Date




    c.            Model Review

This section should describe what (if any) plans/approaches the Project Lead/Lead Engineer
intends to use in having the Development Project review the models.

To facilitate sound and accurate modeling of the system/software, the <Project name> IV&V LE
will review all modeling products to ensure that the models capture the desired system/software
behaviors. In addition, subsequent to this review, the IV&V PL/LE intend to provide applicable
models to the <Project name> for review. <Project name> Project personnel feedback on these
models is desired but not required.


    d.          Dependencies
This section should describe what (if any) dependencies exists with regard to the modeling
efforts described above. Examples include receipt of certain artifacts, etc.

This section documents the dependencies that exist with regard to the modeling efforts described
above.


External
List the external dependencies (items or events controlled by entities external to the IV&V
Program) that drive the modeling efforts.

Internal
List the internal dependencies (items or events controlled by entities internal to the IV&V
Program) that drive the modeling efforts.




<Project name>                                                       Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                     14
                                 IV&V PROJECT EXECUTION PLAN



3.           Validation Plan

This section should describe the validation activities that have been performed and/or completed
to date, and what validation activities are planned for the execution year. This section should
also list the specific products (if any) that will be produced by the Validation Product Line
during the execution year.


     a.           Methodology


     This section should provide a very high-level description of the validation approach. Focus
     on the “what’s going to be done” versus the “hows”. WBS-specific items should be
     identified, as well as the capabilities/areas of the system/software that these activities will be
     performed on, along with the goals/objectives of these efforts. (Note: the “hows” will be
     covered in the Validation Product Line Execution Plan. Tailor the paragraph below for your
     Project.


     Validation is the process of evaluating artifacts to ensure that the right behaviors have been
     defined in the artifacts. The right behaviors are those that adequately describe what the
     system is supposed to do, what the system is not supposed to do, and what the system is
     supposed to do under adverse conditions. Validation ensures that the software system
     performs to the user’s needs under operational conditions.

     The results of the validation efforts will serve as a basis for assessing the goodness of the
     <Project name> software in terms of capabilities and limitations. Capabilities and limitations
     will initially be identified by Validation Product Line personnel. The capabilities will be
     assessed with respect to the development Project’s mission success criteria and the software
     ability to perform/support expected system/software behaviors as defined in the SRM. It is
     expected that the capabilities of the system/software will grow over time as the Project
     progresses through the development lifecycle. Any identified shortcomings of the
     system/software will be reported in terms of limitations with respect to the system/software
     behaviors. The impact of the limitations will be assessed against the development Project’s
     mission success criteria and communicated using the SRM as well as Project artifacts. The
     IV&V LE will review this data and may modify this data (if necessary) prior to distribution
     to the development Project.

     To date, the IV&V efforts have validated requirements at all levels of the system. The FY09
     validation efforts will focus on validation of the test design for <enter some type of text
     describing what levels of the system/software/behaviors>. The goals/objectives of these
     efforts are <enter text here>. The validation test design efforts will be facilitated by the
     models developed by the SRM Product Line as described above.


<Project name>                                                        Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                     15
                                 IV&V PROJECT EXECUTION PLAN


    Requirements are evaluated for all levels of system decomposition and for all aspects (i.e.,
    safety, integration, and dependability requirements) to determine whether or not the defined
    behaviors adequately meet the needs of the system and expectations of its stakeholders and
    users.
    Specific requirements validation tasks to be performed are:
    (Note: If necessary, enter additional text to the WBS elements listed below to further
    supplement the text in IVV 09-01; if not applicable, simply provide the WBS element
    name/number.)

        WBS 1.2.1 Validate System Requirements: <if necessary>
        WBS 1.2.2 Validate Segment Requirements
        WBS 1.2.3 Validate Element Requirements
        WBS 1.2.4 Validate Subsystem Requirements
        WBS 1.2.5 Validate Component Requirements
        WBS 1.2.6 Validate System-Software Safety Requirements
        WBS 1.2.7 Validate Integration Requirements
        WBS 1.2.8 Validate Dependability Requirements


For <Project name>, specific requirements that are applicable for the requirements validation
efforts are defined in Table 2-1 below:
                            Table 3-1: <Project name> Requirement Hierarchy

   Requirements Level                          Applicable Requirements Document




The <enter Project name> test design is evaluated against both the SRM and the validated
requirements. The goal is to verify and validate that the software products meet the specification
and the operational need using the validated test design as a tool. A valid test design meets each
of the following criteria:
             The scope of the test design covers the behaviors identified in the SRM under
               nominal and adverse conditions.
             The scope of the test design covers all of the validated requirements.
             The test cases will exercise the software sufficiently and within the operational
               context to verify that the system behaviors, requirements, and interfaces are
               properly implemented.
<Project name>                                                      Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                    16
                                 IV&V PROJECT EXECUTION PLAN


               The test oracle(s) contain(s) the correct inputs and expected outputs for the
                software behaviors, requirements, and interfaces they are designed to test.
To meet the objective of timely validation, an iterative approach may be required. Each iteration
may include some or all of the following lower-level WBS elements (e.g., 1.3.X) necessary to
validate the different levels of tests (e.g., system, integration, unit). Specific test design
validation tasks to be performed are:

    (Note: If necessary, enter additional text to the WBS elements listed below to further
    supplement the text in IVV 09-01; if not applicable, simply provide the WBS element
    name/number.)


WBS 1.3.1 Validate Scope of Test: <enter text if applicable>.

WBS 1.3.2 Validate Test Cases

WBS 1.3.3 Validate Test Oracle

For <Project name>, specific testing levels/efforts applicable for the planned test design
validation tasks mentioned above are defined in the table below:

 Table 3-2: <Project name> Testing Levels <Modify table to portray what areas of the system at
                         hand test design validation efforts are being applied.>

         Testing Level                                 Applicable Test Artifacts




For additional information/details describing the validation tasks, see IVV 09-01.

    b.            Products

    This section should be a listing of all the validation products that the Validation Product
    Line will produce for the IV&V efforts.

    This section provides a listing of the validation products that the Validation Product Line will
    produce for the IV&V efforts.

                                       Table 3-3: Validation Products

<Project name>                                                          Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                      17
                                 IV&V PROJECT EXECUTION PLAN



Product          Description                                                        Proposed Due Date
Name
Risks            Informal product. Documents IV&V identified risks that are         As applicable
                 related to the development Project. These risks are related to
                 the successful performance of the Project’s mission or to the
                 achievement of the Project’s goals and objectives. These
                 risks will be provided to the LE and/or IV&V PL for further
                 review/consideration prior to submission to the IV&V Risk
                 Review Board.
Project Issue    Documents specific limitations associated with development         As applicable/agreed
Tracking         artifacts analyzed by the IV&V team. These are not official        upon with LE/IV&V PL
System (PITS)    deliverables but are records in PITS that are exchanged
Technical        between the IV&V team and the Project.
Issue
Memoranda
(TIMs)
**Validation     Observations stemming from validation activities that are          As applicable/agreed
Observations     communicated to the Project informally. Unlike TIMs these          upon with LE/IV&V PL
                 may not require a formal disposition from the Project.
<enter type      <TBP enter description of the analysis report if applicable >      TBS
here>
Analysis
Report


**While validation observations do not require tracking in PITS or a formal disposition by the
development organization, they may ultimately result in TIMs or risks if they continue to be
observed is subsequent lifecycle artifacts. Observations are largely a communication tool used to
communicate potential risks or findings that if unaddressed, may result in limitations in the
software.

    c.            Dependencies

This section should describe what (if any) dependencies exists with regard to the validation
efforts described above, examples include receipt of certain artifacts, etc.

This section documents the dependencies that exist with regard to the validation efforts described
above.


External
List the external dependencies (items or events controlled by entities external to the IV&V
Program) that drive the validation efforts.

Internal
List the internal dependencies (items or events controlled by entities internal to the IV&V
Program) that drive the validation efforts.

<Project name>                                                                    Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                           18
                                 IV&V PROJECT EXECUTION PLAN



4.           Verification Plan

This section should describe the verification activities that have been performed/completed to
date, and what verification activities are planned for the execution year. This section should
also list the specific products (if any) that will be produced by the Verification Product Line
during the execution year.


     a.           Methodology

     This section should provide a very high-level description of the verification approach. Focus
     on the “what’s going to be done” versus the “hows”. WBS-specific items should be
     identified, the areas of the system/software that these activities will be performed on, along
     with the goals/objectives of these efforts. (Note: The “hows” will be covered in the
     Verification Product Line Execution Plan.)

     Verification is the process of determining whether the products of each development activity
     fulfill the requirements or conditions imposed by a previous development activity. This goal
     is achieved by showing that each functional and non-functional requirement has been
     implemented within the system. Verification flows from a set of validated requirements and
     formally or informally shows, based on risk, that the implementation of those requirements
     (e.g., desired system behavior/non-behavior) is correct and complete. Verification does not
     strictly focus on functional requirements; it also includes non-functional requirements.

     The results of the verification efforts will serve as a basis for assessing the goodness of the
     <Project name> software in terms of capabilities and limitations. Capabilities and limitations
     will be identified by Verification Product Line personnel. The capabilities will be assessed
     with respect to the software ability to perform/support expected system/software behaviors as
     defined in the SRM. It is expected that the capabilities of the system/software will grow over
     time as the Project progresses through the development lifecycle. Any identified
     shortcomings of the system/software will be reported in terms of limitations with respect to
     the system/software behaviors. The impact of the limitations will be assessed and
     communicated using the SRM as well as Project artifacts. The IV&V LE will review this
     data and may modify this data (if necessary) prior to distribution to the development Project.



     To date, the IV&V efforts have verified some requirements implementation on the spacecraft
     software. The FY09 verification efforts will focus on verifying requirements implementation
     and behavior implementation for <enter some type of text describing what levels of the
     system/software/behaviors>. The goal/objectives of these efforts are <enter text here>. The
     verification efforts will be facilitated by the models developed by the SRM Product Line as
     described above.

     Specific verification tasks that will be performed are:
<Project name>                                                      Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                    19
                                 IV&V PROJECT EXECUTION PLAN


    (Note: If necessary, enter additional text to the WBS elements listed below to further
    supplement the text in IVV 09-01; if not applicable, simply provide the WBS element
    name/number.)

        WBS 2.1 Verify SW Architecture: <enter text here as/if applicable>.
        WBS 2.2: Verify SW Design
        WBS 2.3: Verify Interface Design
        WBS 2.4: Verify System Behavior Implementation
        WBS 2.5: Verify Requirements Implementation
        WBS 2.6 Verify Interface Implementation
        WBS 2.7 Verify System-Software Safety Implementation
        WBS 2.8 Verify Dependability Implementation

For additional information/details describing the verification tasks, see IVV 09-01.

    b.            Products

    This section should include a listing of all the verification products that the Verification
    Product Line will produce for the IV&V efforts.

    This section provides a listing of the verification products that the Verification Product Line
    will produce for the IV&V efforts.


                                        Table 4-1: Verification Products

Product Name              Description                                                Proposed Due Date
PITSTIMs                  Documents specific findings associated with                As applicable
                          development artifacts analyzed by the IV&V team.
                          These are not official deliverables but are records in
                          PITS that are exchanged between the IV&V team
                          and the Project
Risks                     Informal product. Documents IV&V identified risks          As applicable
                          that are related to the development Project. These
                          risks are related to the successful performance of the
                          Project’s mission or to the achievement of the
                          Project’s goals and objectives. These risks will be
                          provided to the LE and/or PL for further
                          review/consideration prior to submission to the Risk
                          Review Board.
<enter type here>         <TBP – enter description of analysis report here if        TBS
Analysis Report           applicable>


    c.            Dependencies



<Project name>                                                                     Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                            20
                                 IV&V PROJECT EXECUTION PLAN


This section should describe what (if any) dependencies exist with regard to the verification
efforts described above. Examples include receipt of certain artifacts, etc.

This section documents the dependencies that exist with regard to the verification efforts
described above.

External
List the external dependencies (items or events controlled by entities external to the IV&V
Program) that drive the verification efforts.

Internal
List the internal dependencies (items or events controlled by entities internal to the IV&V
Program) that drive the verification efforts.




<Project name>                                                     Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                  21
                                 IV&V PROJECT EXECUTION PLAN



5.           Schedule Plan
The PL, in conjunction with the Product Line Leads, shall develop a schedule that represents the
activities for the execution year. Out-year activities may also be included in the schedule if
desired but are not required, as these activities will be defined at a very high level in the out-
year planning section of this plan (Appendix A).
The goal of the IV&V effort is to work in concert with the <enter Project name here>
development activities. The IV&V team maintains a schedule that supports and is consistent
with the development efforts. The IV&V schedule, in Microsoft Project, is maintained
throughout the IV&V effort. The schedule is consistent with the IV&V WBS and is constructed
using the IV&V notational network diagram template available at:
http://www.nasa.gov/centers/ivv/ims/templates/index.html

The IV&V schedule associated with this plan is baselined prior to execution of the activities
described in this plan. The baseline IV&V schedule is maintained by the IV&V PL, resides on a
server at the IV&V Program, and is available upon request.




<Project name>                                                     Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                  22
                                 IV&V PROJECT EXECUTION PLAN



6.              Resource Plan and Funding Profile

The purpose of this section is to inform the IV&V Program of your plan for utilizing IV&V
resources, NASA (Project Lead), and contractor resources (Lead Engineer) on your project, and
the associated (estimated) costs for the Lead Engineer resources.

Total estimated costs for IV&V support for the FY09 <enter Project name> IV&V efforts as
described in this plan and specifically the subsections below are <enter total Project estimated
costs here>. The only costs directly captured in this IPEP are the costs for the Lead Engineer
and any costs associated with Lead Engineer travel.

     a.            IV&V Services

          (1)         Project Lead

          Calculate staff months as follows: % of entity * duration in months for applicable
          timeframe (typically this FY); for example, if you expect PL to be .50 FTE for the entire
          FY, then calculation is as follows: 0.50 X 12 = 6 staff months.

          Project Lead resources will come from IV&V Services. For <enter Project name>
          IV&V, it is estimated that <X> staff months of a PL are required to support the efforts
          described in this plan. The PL is a civil servant.

          (2)         Lead Engineer

          Use the applicable paragraph(s) below to describe your situation for Lead Engineer
          support (either contractor or civil servant).
          Lead Engineering resources will come from an IV&V Services contract vehicle. It is
          estimated that <X> staff months of an LE are required to support the efforts described in
          this plan. The LE is a contractor. Estimated costs for this fiscal year for these services
          are <enter $ amount>.

          Lead Engineering resources will come from IV&V Services/IV&V Engineering Services.
          It is estimated that <X> staff months of an LE are required to support the efforts
          described in this plan. The LE is a civil servant.




   b.         Travel
Provide high-level description of required/planned travel for the execution year for the resources
mentioned above. If there are none, state “none”.

A high-level description of required/planned travel for the execution year for the resources
mentioned above is provided in this section.
<Project name>                                                       Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                    23
                                 IV&V PROJECT EXECUTION PLAN




       (1)         IV&V Services
       For travel dates in these tables that are related to lifecycle reviews, please include in the
       purpose/intent field text that indicates if IV&V Services personnel will be presenting at
       the review.
                                        IV&V Project Lead
   Date(s)      Milestone/Event        Destination           Purpose/Intent




                                       IV&V Lead Engineer
   Date(s)        Milestone/Event      Destination      Purpose/Intent                  Estimated
                                                                                          Costs




<Project name>                                                      Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                   24
                                   IV&V PROJECT EXECUTION PLAN


7. Management Plan

This section describes how the IV&V efforts are managed and organized. The generalized
diagram in Figure 7-1, IV&V Team and Project Interfaces, should be replaced with one or more
diagrams that represent the interfaces for your actual Project and the IV&V Team. The diagram
should show the desired formal and informal communication paths.
The authority to execute IV&V on NASA projects is provided in NASA Software Policy, NPD
2820. Consistent with this NPD, the IV&V team functions technically, managerially, and
financially independent of the <Enter Project name> Project. The IV&V Team functions as an
independent group conducting validation and verification of the development Project safety and
mission critical software. The IV&V Team consists of representatives from the following
organizations: NASA IV&V civil service employees (NASA IV&V PLs/LEs and Engineering
Services [Product Lines]), IV&V contractors (typically LEs and Product Line support
personnel).
Figure 7-1, IV&V Team and Project Interfaces, illustrates the communication channels between
the IV&V Team and the Project (solid line = formal channel, dashed line = informal channel).


                                       Project Manager




                   Development          IV&V Point of                        NASA IV&V
                    Contractor            Contact                            Project Lead


                                                             Systems
                                                                                                     IV&V Product
                                                            Assurance
                                                                                                        Lines
                                                             Manager


                                                                                  Lead Engineer
                                                         Software Quality
                                                         Representatives




                                                         Informal




                                 Figure 7-1 – IV&V Team and Project Interfaces

    a. Roles and Responsibilities

To facilitate successful execution of the IV&V efforts as described in this plan, various roles and
responsibilities must be fulfilled. These roles and responsibilities can be described in terms of
internal (personnel within the IV&V Program) and external (personnel outside the IV&V
Program (development Project representatives). The subsections below describe at a high level
these roles and responsibilities.


         1. Internal Roles and Responsibilities

<Project name>                                                                              Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                                        25
                                 IV&V PROJECT EXECUTION PLAN


(This section should be fairly static and not require much, if any, tailoring; however, if
necessary, tailor for your project)
The PL and IV&V Lead Engineer serve as the primary interfaces with the <enter Project name>
Project, their roles and responsibilities are described below.
            IV&V Project Lead – the PL is a civil service employee that is responsible for the
             overall leadership and direction of the <enter Project name> IV&V efforts. The PL is
             responsible for establishing the goals and objectives of the IV&V efforts, performing
             the PBRA efforts, performing project management/financial management, project
             tracking and oversight and risk management of the IV&V efforts. The PL is
             responsible for ensuring that the commitments with the <<enter Project name>
             Project, including but not limited to the exchange of IV&V deliverables as defined in
             this plan and/or the <enter Project name> formal agreement/MOA, are met. The PL
             is the primary interface for the IV&V efforts with the <enter Project name> Project.
            IV&V Deputy Project Lead – (Tailor this text as applicable for your DPL or delete
             if N/A.) The DPL is a civil service employee that supports the PL in performing the
             duties and responsibilities of the PL as described above.
            IV&V Lead Engineer – (Tailor this for your Project.) The LE is a civil servant or
             IV&V contractor that is responsible for supporting the PL and overall IV&V efforts
             from a technical perspective. Specifically, the LE is responsible for assisting the PL
             in establishing the goals and objectives of the IV&V efforts, supporting the PBRA
             efforts, ensuring that the proposed analysis is appropriate and feasible given the
             characteristics of and maturity of the software development efforts, reviewing
             analysis results from the Product Line to ascertain the capabilities and limitations of
             the system/software, documenting and communicating the results of the analysis
             (―goodness of product‖) in terms of capabilities/limitations, TIMs, observations and
             risks to the <enter Project name> Project as well as at various other forums. The LE
             also serves as an interface with the <enter Project name> Project.
            IV&V Product Line Lead – the Product Line Lead(s) is/are responsible for working
             with the PL to establish an agreed upon plan/approach to meeting the requirements
             and needs of the IV&V efforts. The Product Line Lead(s) is/are responsible for
             producing the agreed upon products for their applicable product line consistent with
             the requirements described in this plan (see sections 2-4 specifically). The Product
             Line Lead is responsible for monitoring and tracking progress of their efforts and
             communicating regular status of these efforts to the PL. Regular tag-ups will be held
             between the PL, LE, and Product Line Leads/Product Line Support staff to coordinate
             status of tasking, products, risks, concerns, etc. The Product Line Leads are
             responsible for notifying the PL if any risks are identified to the agreed upon
             plan/approach as well as any risks to meeting the technical goals of the analyses being
             performed.

The table below defines the contact information for IV&V personnel supporting and/or involved
with the IV&V efforts.
                             Table 7-1 – IV&V Team Contact Information

<Project name>                                                       Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                    26
                                 IV&V PROJECT EXECUTION PLAN


                                       NASA IV&V Program
 Position                               Name                   Contact Information
 IV&V Program Manager                   Dr. Dale Scott         304-367-8201
                                        Caffall                Dale.S.Caffall@nasa.gov
 IV&V Chief Integration Officer         Leigh Gatto            304-367-8308
                                                               Leigh.J.Gatto@nasa.gov
 IV&V Chief Engineer                    Marcus Fisher          TBP
 IV&V Mission Directorate Lead          <enter name>           TBP
 IV&V NASA IV&V Project Lead            <enter name>           TBP
 IV&V NASA IV&V Deputy                  <enter name>           TBP
 Project Lead (if applicable)
 IV&V Lead Engineer (if                 <enter name>           TBP
 applicable)

         2. External Roles and Responsibilities
(Tailor this section to reflect the roles/responsibilities that have been established on your Project
for the development Project personnel.)
The description of the roles and responsibilities of external personnel as described below is not
intended to be an exhaustive and/or complete listing for the <enter Project name> Project, but
reflects roles and responsibilities pertinent to the IV&V efforts.
            NASA Development Project Manager/Deputy Project Manager: serves as the
             primary <enter Project> Project contact for the IV&V efforts, facilitates/authorizes
             the provision of IV&V Point(s) of Contact for the <enter Project> Project as
             applicable. Ensures and facilitates Project commitment to the IV&V efforts as
             defined in the formal agreement/MOA and this plan.
            IV&V Point(s) of Contact: serves as the designated <enter Project name> Project
             interface for the <Project name> IV&V efforts. Responsible for provision of
             development Project-related artifacts and associated schedules in support of the
             IV&V efforts (electronic access is preferred). Responsible for review of IV&V
             analysis results and ensuring appropriate levels of coordination in terms of resolution
             of any shortcomings with the system/software as revealed from these analysis results.
            Chief Safety Officer: (Remove this section if not applicable or relevant to your
             Project. CSO is what used to be the System Assurance Managers.) responsible for the
             safety and mission assurance activities for the <enter Project> Project. Guides the
             overall SMA efforts for the <enter Project> Project including the software assurance,
             including SQA activities. As necessary, assists the IV&V POCs in the resolution of
             any shortcoming with the system/software as revealed by IV&V analysis results.
            Software Assurance Personnel (SQA, SW Safety) (if applicable): <enter text
             describing SA personnel roles for your Project>.
<Project name>                                                       Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                    27
                                 IV&V PROJECT EXECUTION PLAN


            Software Development Lead (if applicable): <enter text describing SW
             development personnel roles for your Project>.

                                Table 7-2 – Project Contact Information

                                                 Project
 Position/Role                            Name                 Contact Information
 Project Manager                          TBP                  TBP
 Deputy Project Manager                   TBP                  TBP
 IV&V Point of Contact                    TBP                  TBP
 Chief Safety Officer (if                 TBP                  TBP
 applicable)
 Software Quality Assurance               TBP                  TBP
 (SQA) Representative (if
 applicable)
 Software Development Lead (if            TBP                  TBP
 applicable)




<Project name>                                                     Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                     28
                                 IV&V PROJECT EXECUTION PLAN


8. Risk Management Plan

Risks will be identified, managed, tracked and controlled as described in IVV 09-09, Risk
Management and Guidelines for Risk Management S3001.

IV&V is a risk mitigation tool for the Agency and will identify risks of the following types:
    Development Project-related risks – risks to the successful performance of the Project’s
      mission or to the achievement of the project’s goals and objectives (not limited to
      software; addresses both safety and mission success aspects). These risks may be either
      product or process related.
    IV&V risks – risks to the successful performance of IV&V.

Specific risks applicable to the IV&V efforts described in this IPEP are maintained by the IV&V
Project Lead in conjunction with the IV&V Risk Review Board. Such risks are available upon
request. The IV&V Project Lead shall communicate these risks to the MDL as part of the
development of this IPEP as well as throughout the execution of this plan.

External Dependencies

(List any external dependencies with regard to risk management [e.g. Project’s risk management
plan, access to risk management tool/systems, etc.]).

   TBD/TBP



Internal Dependencies

(List any internal dependencies with regard to risk management.)

   TBD/TBP




<Project name>                                                     Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                 29
                                 IV&V PROJECT EXECUTION PLAN



Appendix A: Out-year Planning and Profile

The intent of this section is to provide information of the IV&V efforts from a full lifecycle
perspective. This information represents/documents the initial Project baseline (or the current
mod/version) from a full lifecycle perspective to facilitate out-year planning, resource planning,
and budgeting/forecasting efforts for the Program. This information should provide a big
picture of your IV&V Project and serve as an initial starting/reference point for planning your
IV&V efforts each execution year. This information should allow the Program as well as the
IV&V Project Lead to make informed decisions about this IV&V Project.

         a. IV&V Goals/Objectives

The intent of this section is to identify high-level goals/objectives for remaining out-years on this
Project. Show data for all applicable out-years. Description can be written from a capabilities
or thread perspective if known/applicable.

<Enter Project name> launch is scheduled for <enter date XX/XX/XX>. All <enter Project
name> IV&V analyses related activities are currently scheduled to complete in <enter timeframe
here….e.g., late GFY0X>. Support for the <enter Project name> Project in out-years (GFYXX
and beyond) is limited to milestone review support.


Fiscal Year                       Goals/Objectives                       Description

FY10               Develop/maintain SRM                          Model system, spacecraft,
                                                                         instruments
                   Validate Requirements                       S/C requirements, instrument
                                                                        requirements
                   Validate Test Design                        S/C testing, Instrument testing
                   Verify SW Architecture                                  S/C only
                   Verify SW Design                                        S/C only
                   Verify Requirements Implementation                      S/C only
FY11               Validate Test Design                        S/C testing, Instrument testing
                   Verify SW Design                                        S/C only
                   Verify Requirements Implementation                      S/C only
                   Verify Behavior Implementation                          S/C only
FY12               Validate Test Design                        S/C testing, Instrument testing
                   Verify Requirements Implementation                      S/C only
                   Verify Behavior Implementation                          S/C only
FY13               Milestone Review Support                     SMSR, MRR Attendance and
                                                                participation (briefing to be
                                                                     provided by IV&V)


         b. Funding Profile
<Project name>                                                       Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                     30
                                 IV&V PROJECT EXECUTION PLAN


Provide a short description that describes to some extent what comprises the identified costs in
the table below; tailor the sample text below accordingly.

Funding in FYXX is limited to LE estimated salary costs and costs associated with travel for
milestone review support. An estimate of the costs is $1000; $500/trip, with one trip for the
SMSR and one trip for the MRR. Both reviews are expected be one-day meetings, conducted at
GSFC in Greenbelt, MD.


Fiscal Year        IV&V
                   Services
                   Allocation
FY10               200K
FY11               200K
FY12               105K




<Project name>                                                     Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                  31
                                 IV&V PROJECT EXECUTION PLAN


Appendix B: IV&V Portfolio Based Risk Assessment (PBRA) Results

In order to properly allocate funding across IV&V projects, the IV&V Program utilizes a PBRA
approach. The PBRA process begins with an initial assessment of each capability for a particular
mission in terms of impact of a limitation and likelihood of a limitation. Initially the IV&V PL
and LE, in collaboration with the MDL, perform the PBRA. The result of this assessment is an
overall rating for each capability for that mission that can be mapped against a 5X5 risk matrix
(see diagram below). Subsequently, all of the PBRA results for each mission are collected and
analyzed together from an IV&V Program perspective. Capabilities that are in the ―green‖ (low
risk) category will not receive IV&V. Capabilities that are in the ―red‖ category will typically
receive IV&V. Capabilities that are in the ―yellow‖ category may receive IV&V, pending
funding availability.

PBRA results/assessment ratings for each Project are revisited every six months (or earlier, if
warranted) by the IV&V PL and LE. If there are any changes to the PBRA results, the IV&V PL
and LE shall analyze these changes to determine/assess the impact of these changes to the IV&V
Project baseline. Subsequently the IV&V PL shall communicate the changes to the MDL, and
an appropriate course of action will be determined (propose a change to the IV&V Project
baseline [see section 10]).

As the PBRA results are a critical driver to IV&V coverage on a particular Project, the IV&V PL
shall share these results as well as any updates to the initial results with the development Project.
The development Project may provide comment/additional insight on the PBRA results to the
IV&V PL for consideration.

PBRA results for the <Project name> IV&V efforts are identified below. The supporting
data/rationale for these ratings is maintained by the IV&V PL and is available upon request.




<Project name>                                                      Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                   32
                                  IV&V PROJECT EXECUTION PLAN



     <enter Project name> IV&V PBRA
     Results
                                                                          Capabilities
P                                                                J1.Launch Flight System
r                                                                J2.Fly to Jupiter
o                                                                J3.Perform Jupiter Orbit
b                                                                Insertion (JOI)
a                                                                J4.Obtain Science and
b                                                                Supporting Engineering Data
i                                                                J5.Change Trajectory
                                                                 J6.Maintain Flight System
l                                           J4             J1
                                 J6
                                                 J7   J3         J7.Deorbit Flight System
i                                      J5
                                                           J2
t
y
                        Impact




                                                                                         21




<Project name>                                                                        Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                                33
                                  IV&V PROJECT EXECUTION PLAN




 Appendix C: IV&V Coverage


 With respect to full and partially covered, coverage is defined as follows:
     Covered – a behavior target is validated and verified (Requirements, Design, Code, Test)
        with respect to all three questions.
     Partial Coverage – some IV&V has been performed on a given software behavior.
     None – no IV&V work has been performed on a given software behavior.

 Include in this section the top level use diagram(s) (if they exist) to show where software is
 involved, what type of software is involved, and which capabilities/behaviors are receiving IV&V
 services. A top level use case diagram should suffice here; however if additional diagrams are
 necessary to convey the message, include them here as well. For new Projects that do not have
 any modeling/use case diagrams, simply list the capabilities that were identified by the IV&V
 PBRA with an indication as to whether the capabilities will receive IV&V coverage (full/partial)
 or not. If necessary, additional text can be provided to identify areas of the system (spacecraft,
 instruments, launch vehicle, etc.) that are planned to receive IV&V, as well as those that are not.




Ref ID    Description                                                       Coverage
G1        Initialize Hardware and Software Systems                          Full

 <Project name>                                                     Effective Date: MM/DD/YYYY
 IPEP Template, T2103, Revision Basic

                                                   34
                                 IV&V PROJECT EXECUTION PLAN


G2       Normalize Spacecraft Spin                                            Full
G3       Deploy Solar Array Panels and RF Antenna                             Full
G4       Capture and Store Science and State of Health Data                   Full
G5       Downlink Science and SOH Data                                        Partial
G6       Receive Commands from Ground                                         Partial
G7       Decode and Validate Commands                                         Full
G8       Execute Commands                                                     Full



IV&V Coverage Definitions:
Covered            (also called Full IV&V) Fully addresses all three questions for ALL
                   safety and mission critical software capabilities. Capabilities in the ―red‖
                   area are generally planned for Full IV&V.
Not Covered        (also called None) No IV&V
Partly Covered     (also called Partial IV&V) Anything between ―None‖ and ―Full‖ (e.g.,
                   may not answer all three questions or may not cover all safety and mission
                   critical software capabilities). Capabilities in the ―yellow‖ area are
                   generally planned for Partial IV&V.

Software Criticality Definitions:
Safety critical (per Pg. 15 of NASA-STD-8719.13B)
               4.1.1.2 Software shall be classified as safety critical if it meets at least one of the
               following criteria:
               a. Resides in a safety critical system (as determined by a hazard analysis) AND at
               least one of the following apply:
                       1) Causes or contributes to a hazard.
                       2) Provides control or mitigation for hazards.
                       3) Controls safety critical functions.
                       4) Processes safety critical commands or data (see note 4-1 below).
                       5) Detects and reports, or takes corrective action, if the system reaches a
                               specific hazardous state.
                       6) Mitigates damage if a hazard occurs.
                       7) Resides on the same system (processor) as safety critical software (see
                               note 4-2 below).
               b. Processes data or analyzes trends that lead directly to safety decisions (e.g.,
               determining when to turn power off to a wind tunnel to prevent system
               destruction).
               c. Provides full or partial verification or validation of safety critical systems,
               including hardware or software subsystems.

Mission critical (per NPR 8715.3C, Appendix B)
              Item or function that must retain its operational capability to assure no mission
              failure (i.e., for mission success).
<Project name>                                                        Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                    35
                                 IV&V PROJECT EXECUTION PLAN


            (per NPR 7150.2, Appendix B)
            Class B Non-Human Space Rated Software Systems are defined as ―Flight and
            ground software that must perform reliably in order to accomplish primary
            mission objectives. Examples of Class B software for non-human (robotic)
            spaceflight include, but are not limited to, propulsion systems; power systems;
            guidance navigation and control; fault protection; thermal systems; command and
            control ground systems; planetary surface operations; hazard prevention; primary
            instruments; or other subsystems that could cause the loss of science return from
            multiple instruments.‖
IV&V Safety critical
            Used to identify software capabilities that IV&V believes should be Safety critical
            (in cases where the project has not completed a hazards analysis that addresses
            software causal factors and therefore cannot meet the ―a‖ Safety critical criteria
            OR the Project has not yet identified/documented/tagged their Safety critical
            software.




<Project name>                                                  Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                36
                                          IV&V PROJECT EXECUTION PLAN


Appendix D: Financial Baseline


           a. Total Project Costs

The total estimated costs for the IV&V support for FY09 activities covered by this IPEP are <$>.


           b. Costs (by month and total)

Include a table with breakout of costs per month for the fiscal year. This should be represent
your Project’s cost baseline for the execution year and should be consistent with what is
submitted to RMO for your Project/what is tracked at the RAC.

Cost projections per month for the fiscal year are listed below.
FY0X
IV&V Services   Oct       Nov       Dec         Jan       Feb       Mar        Apr       May       Jun       Jul       Aug       Sept       Totals
Lead Engineer                                                                                                                                        0
Travel                                                                                                                                               0
Totals                0         0           0         0         0          0         0         0         0         0         0          0            0




<Project name>                                                                                      Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                                                          37
                                 IV&V PROJECT EXECUTION PLAN


Appendix E: Acronyms




<Project name>                                           Effective Date: MM/DD/YYYY
IPEP Template, T2103, Revision Basic

                                               38