+------+---------------------------------------------------------------+
| !    | FSW Code Inspection Standard                                  |
| [](m |                                                               |
| edia | Flight Software Systems Branch -- Code 582                    |
| /ima |                                                               |
| ge1. | Version 1.0 -- 10/28/08                                       |
| png) |                                                               |
| {wid | 582-2005-007                                                  |
| th=" |                                                               |
| 6.37 |                                                               |
| 0138 |                                                               |
| 8888 |                                                               |
| 8888 |                                                               |
| 9in" |                                                               |
| h    |                                                               |
| eigh |                                                               |
| t="7 |                                                               |
| .811 |                                                               |
| 1111 |                                                               |
| 1111 |                                                               |
| 1111 |                                                               |
| in"} |                                                               |
+------+---------------------------------------------------------------+

# Update History

  --------------------------------------------------------------------------
  Version   Date       Description                          Affected Pages
  --------- ---------- ------------------------------------ ----------------
  1.0       10-28-08   Mike Tilley - Incorporated           All
                       additional comments from Lisa Hoge   
                       and Dan Berry; formatting changes;   
                       updated references; removed unused   
                       list entries & renumbered lists.     

  1.0       2-29-08    K. Narayanan -- Incorporate comments All
                       from D. McComas and L. Hoge. Replace 
                       Appendix A.                          

  0.6       8-15-05    Incorporated contents of Appendix A  Pages 3 through
                       into the body of the document.       6 and A-1
                                                            through A-3.

  0.5       7-06-05    Review -- by John Otranto.           All
                       Incorporation of walkthrough         
                       comments and changes, with           
                       enhancements.                        

  0.4       6-30-05    Review -- by John Otranto. Edited    All
                       text based on walk-through meeting   
                       held on 6-30-05. Attendance sheet    
                       available.                           

  0.3       6-30-05    Draft -- by John Otranto. Edited     All
                       text based on comments received from 
                       D. McComas, G. Smith, and Glenn      
                       Cammarata.                           

  0.2       6-19-05    Draft -- by John Otranto. Revised    D-1,2,3;
                       forms in Appendices D, E, and F,     E-1,2,3,4;\
                       consistent with comments received.   F-1,2,3,4

  0.1       6-6-05     Draft -- by John Otranto, based on   
                       input from multiple sources          
  --------------------------------------------------------------------------

# Contents

1.0 Introduction [1](#introduction)

2.0 References [1](#references)

3.0 Entry Criteria [2](#entry-criteria)

4.0 Inspection Materials and Distribution
[3](#inspection-materials-and-distribution)

5.0 Required Attendees/Inspection Team Composition
[4](#required-attendeesinspection-team-composition)

6.0 Inspection Process [5](#inspection-process)

6.1. Roles and Responsibilities [5](#roles-and-responsibilities)

6.1.1. Author [5](#author)

6.1.2. Moderator [5](#moderator)

6.1.3. Recorder [6](#recorder)

6.1.4. Inspectors [7](#inspectors)

6.2. Inspection Team [7](#inspection-team)

6.2.1. Inspectors from a Development Background
[7](#inspectors-from-a-development-background)

6.2.2. Inspectors from a Testing Background
[8](#inspectors-from-a-testing-background)

6.2.3. Inspectors from Other Engineering Disciplines
[8](#inspectors-from-other-engineering-disciplines)

6.3 Heritage/Reused Software Review [9](#heritagereused-software-review)

6.4. Auto-Generated Code Review [9](#auto-generated-code-review)

7.0 Decorum [10](#decorum)

8.0 Follow-up [11](#follow-up)

Appendix A - Sample Inspection Log and Participants Forms
[12](#appendix-a---sample-inspection-log-and-participants-forms)

# 1.0 Introduction

This standard describes the Goddard Space Flight Center (GSFC) Code 582
Flight Software Systems Branch (FSB) inspection policies for Flight
Software (FSW) code.

FSW is inspected as part of the development process. The inspection's
primary objective is to improve the software quality through early
detection of coding and style problems, comparison of code's
implementation to associated requirements, and analysis of FSW
testability and operability. Additional inspection benefits include
creating a consistent software product and distributing knowledge about
the software throughout the FSW team. Inspections shall be scheduled to
allow sufficient time for a developer to make changes and complete unit
testing prior to software release.

The FSW inspection process represents the best practices, confirmed by
experience, from References 1, 2, and 3, lessons learned from past
successful inspections processes within the FSB, and published
experience reports from industrial organizations. Further, this FSW
inspection standard incorporates processes and standards piloted and
codified at other NASA Centers; the experiences of NASA project teams
have proven these recommendations effective.

# 2.0 References

1 *ISD Software Policies*, no. 580-PL-002-02, PAL Number: 1.0.0.1, GSFC
Software Engineering Division, Code 580, dated 4/20/2005.

2 *NASA Software Engineering Requirements*, NASA Headquarters Procedural
Requirements NPR 7150.2, NASA Headquarters, Office of the Chief
Engineer, dated 9/27/2004.

3 *NASA Software Policy*, NASA Headquarters Policy Directive: NPD
2820.1C, Office of the Chief Engineer, dated 8/31/2005.

4 FSW DCR Requirements, 582-2005-002, Flight Software Systems Branch,
Code 582, Version 1.3, dated 11/27/2006.

5 FSW Requirements for Maintainability, 582-2006-013, Flight Software
Systems Branch, Code 582, Version 3.1, dated 03/13/2007.

# 3.0 Entry Criteria

Before subjecting FSW to inspection, the author(s) should ensure that
FSW meets the following criteria:

A. The FSW addresses specific, and documented requirements.

B. A documented design exists for FSW functionality and interfaces. A
PDR or CDR representation can be sufficient.

C. The FSW addresses all possible nominal execution and exception/error
scenarios, or provides the capability to address alternate scenarios in
the future.

D. The FSW code is adequately commented and it compiles.

# 4.0 Inspection Materials and Distribution

The author should prepare FSW for inspection by preparing a FSB Code
Review Package (CRP). The CRP should include all material required for a
reviewer to evaluate the code unaided. The CRP should provide the
following and meet the following criteria:

A A summary page, documenting:

1 The author's name, co-authors, and the schedule review date and time.

2 The date of the package distribution.

3 A summary of the code's purpose.

4 Requirements met or addressed by this FSW under review.

5 A list of the files to be reviewed.

6 Requirements, design, algorithms, and other relevant parent
documentation\
(these may be included by reference).

B The CRP includes FSW detailed design, requirements, algorithms, and
other relevant parent documentation, available in an electronic format,
preferably including process flow diagrams. Each project may define a
file format or representation standard for design presentation.

C The CRP includes all source files including relevant header files,
with the exception of system-level include files; files in the standard
include directory are not required. Source files should be shown with
line numbers.

D The CRP should normally be distributed no less than 3 days before the
inspection so that the review team members have adequate opportunity to
review the FSW prior to formal review.

E The review material should be provided in advance to all reviewers in
an electronic format, such as an email attachment, and/or as a
downloadable file or set of files at a specific web/FTP location. A
distribution of a hardcopy of the review material may be used if
necessary or as a fallback.

# 5.0 Required Attendees/Inspection Team Composition

All participants in an inspection should be able and prepared to
contribute to the review. The code author conducting the FSW inspection
is responsible to invite representatives in the technical roles as
defined in this section.

These representatives shall be invited and must be present at the
inspection:

A Author(s): All developers who authored the FSW undergoing inspection.
(For heritage code, a technical representative may be substituted.)

B Development Team Lead (DTL) for the FSW.

C Hardware system or subsystem engineer(s) on which the FSW operates,
and the GN&C analysis team, if appropriate to the software being
inspected.

Representatives from the following categories shall be invited to
participate in the inspection, although they may decline without causing
the inspection to be rescheduled:

A The FSW Product Development Lead (PDL).

B Test Team representatives who are responsible for testing the FSW
undergoing review. Testers look for defects in the FSW from the
perspective of their areas of expertise, making certain the FSW is
testable, and finding anomalous conditions.

C A software quality assurance representative (Code 300).

D IV&V (if the team has IV&V support).

E FSW persons not directly responsible for generating the inspected
product. These persons may be working on the same FSW mission or a
different mission.

F Representatives from interfacing components or configuration items,
who will inspect this FSW from the perspective of using or working with
the FSW.

G Users such as flight hardware developers, flight operations personnel,
science data processing, and science data analysts can be candidates,
based on the relevance of the FSW to these roles. These candidates
ensure the FSW successfully operates in their area of expertise.

# 6.0 Inspection Process

The FSW code author shall conduct the meeting. Information about the
participants is noted on the Code Inspection Participants Form (see
Appendix A). The FSW author(s) will begin the meeting by summarizing the
requirements and design of the FSW, and then step through the code
modules, providing details and explanations as needed to ensure all
review team members understand the code. At any time, any member of the
review team can raise an inquiry to be addressed. All issues raised by
the team are recorded on a Code Inspection Log Form (see Appendix A),
typically on a spreadsheet electronically.

## 6.1. Roles and Responsibilities

### 6.1.1. Author

The FSW developer is the author for FSW inspection. For the review, the
author shall:

A. Compile the CRP, any additional reference documents (or provide
links), along with a cover sheet, and send the completed package to
participants at least 3 days before the inspection meeting is scheduled.

B. Distribute all work products for inspection including required
reference materials.

C. Invite mandatory participants for the inspection team. The inspection
must be rescheduled if any of the required participants or their
representative cannot be present in the inspection.

D. Conduct the code inspection process during the meeting:

1\. Provide a brief overview of the code, based on the summary material
provided.

2\. Provide a reading of the FSW code during the meeting, explaining the
actions of code segments as appropriate, and stepping through the code
in a timely manner.

3\. Explain code nuances.

E. Respond to questions about the function, purpose, and organization of
the inspected product and the associated reference materials.

F. Following the inspection, modify the inspected product to correct
defects found during the inspection, fixing all defects on the team
list, and distributing the results for approval by the moderator when
the work is complete.

G. Review the corrections with the moderator according to the
requirements in Section 8.0.

### 6.1.2. Moderator

The moderator oversees the inspection and is responsible for the overall
effectiveness of the inspection. The role of moderator is performed by a
person other than the author, and is typically the author's DTL. (The
DTL may designate a willing, qualified inspection moderator if he/she
chooses not to serve as the moderator.) Specific responsibilities of the
moderator are:

A Ensure that the entry criteria specified in Section 3.0 are met.

B Make sure that a meeting room and any necessary facilities (e.g.
projector, laptop connection) have been reserved for the inspection
meeting.

C Invite any additional participants who can contribute to and/or learn
from the inspection. Team size should typically not be less than four,
however, care should be taken to not have too large a team in order to
avoid loss of productivity. Familiarize these attendees with the decorum
issues described in Section 7.0.

D Check if the required participants are present. The inspection must be
rescheduled if any of the required personnel are not represented in the
inspection.

E Initiate the meeting, detailing the meeting's purpose, scope, time
limit, and decorum. Set the pace for the meeting. Introduce people and
their project roles, if appropriate. Ensure attendance of every required
participant.

F Be prepared to discuss issues raised by other participants in a fair
way and reach a decision as to whether or not a fix or change is
necessary.

G Ensure that the meeting stays focused on raising and discussing any
possible quality or technical issues in the product under inspection.
Review with more than seven attendees must be well-managed (comment--
and conversation--constrained) to ensure meeting efficiency and
timeliness.

H Conclude the meeting and perform follow-up as described in Section
8.0.

I Review all changes made in response to the inspection results, verify
that all dispositioned defects are corrected prior to re-inspecting, and
verify that no new defects are inserted into the code.

J Complete the inspection:

1\. Approve the changes when satisfactory and submit the Code Inspection
Log Form into CM.

2\. Ensure the changed components are placed under CM control.

### 6.1.3. Recorder 

The recorder will document each defect with classification identified
during the inspection meeting and provide the resulting list to the
moderator at the end of the inspection meeting. A person other than the
author shall perform the role of recorder in an inspection; the
moderator can also fulfill this role.

A Record the participant information on the Code Inspection Participants
Sheet as shown in Appendix A.

B Begin filling out the Code Inspection Log Form (Appendix A) with known
information.

C Record any issues that the moderator determines requires a fix/change
to the code on the Code Inspection Log Form.

D Record any action items that cannot be resolved at the time of the
meeting but reflect important quality issues, along with a name
responsible for closing the action item on the Code Inspection Log Form.

E Log the total time spent at the meeting.

G. Provide the Code Inspection Log Form to the moderator.

### 6.1.4. Inspectors 

Additional personnel not fulfilling the roles of author or moderator are
chosen from the other candidates listed in section 5.0.

The inspectors shall:

A Take adequate time to prepare by reviewing the code undergoing
inspection and noting any potential quality issues.

B Take notes on issues to raise during the inspection meeting for team
discussion.

C Participate in the inspection meeting. Raise any issues found during
preparation, or that occur during the inspection meeting, that require a
fix or change to the document.

D Be prepared to discuss issues raised by other participants consistent
with proper meeting decorum.

E Remain focused and professional at all times and never behave in a
disrespectful manner toward colleagues in the inspection.

## 6.2. Inspection Team 

Each member of the inspection team (moderator, peers, users, etc.)
should look for errors in logic, code that may have a negative impact on
performance, deviations from the stated design, and omission of
necessary functions and comments. Further, the team should identify
deviations from FSB coding standards and approved waivers.

### 6.2.1. Inspectors from a Development Background

Inspectors representing a development perspective (author, peers, and
moderator) should review the development package while considering how
they would design and implement the functionality described. While doing
so, they should record any issues they find, and focus on the following
questions:

-   Does the FSW code satisfy the requirements?

-   Review the FSW code as implemented. Considering the end
    functionality the software should provide -- is there unnecessary
    complexity?

-   Will the software as specified be able to support likely on-orbit
    maintenance needs, including those detailed in reference 5, FSW
    Requirements for Maintainability.

-   Are the error indications, flags, and counters handled properly?

-   Is the FSW code sufficiently commented? As a developer, how easy or
    difficult would it be to modify this code in terms of understanding
    and changing some aspect of the functionality?

-   Are software modules reused within the evaluated FSW? Are
    modifications to the reused components clearly identified and
    appropriately commented (for example, why modifications were
    performed)?

-   Will components function properly under all potential conditions?

-   Other consideration, as applicable:

    -   Is the command counter incremented when appropriate?

    -   Are parameters for every command appropriately checked and if
        errors are detected, is an event message generated and
        transmitted?

    -   Do all startup parameters go into the configuration tables?

    -   Is there adequate information in telemetry to verify FSW
        functions during integration and test, and flight operations?

    -   Where are data values (transitions, constructors, etc.)
        initialized?

    -   Is the telemetry packet sequence counter incremented for each
        packet sent?

    -   Does the code provide a NOOP command and reset-counters command?

### 6.2.2. Inspectors from a Testing Background

Inspectors representing a testing perspective should consider how they
would develop a test case or set of test cases to evaluate the FSW.
While doing so, they should record any issues they find, and should
focus on the following questions:

-   What is required to verify the FSWrequirements?

    -   How could a test program be used to verify the FSW?

    -   What operations procedure scenarios could be developed to verify
        the FSW?

    -   What validation data would result that verify the correct
        operation of the test procedure?

    -   How will validation data be recorded, collected, and analyzed?

-   Are error/off-nominal situations addressed as completely as
    possible?

    -   Is it clear which types of anomalies generate asynchronous event
        messages?

    -   Are all the potential error conditions addressed, including
        non-nominal conditions?

### 6.2.3. Inspectors from Other Engineering Disciplines

Inspectors knowledgeable in hardware, product interfaces, algorithms,
GNC, and science applications should focus on understanding the FSW
described as a whole and in the context of their specialty. While
focusing on those interfaces, they should record any issues they find,
although they should especially focus on the following questions:

-   Is the context of the software system correctly understood? Are the
    interfaces for all external dependencies identified and correctly
    implemented?

    -   Does the FSW correctly use interfaces as intended? That is, does
        the FSW use and interpret data correctly, e.g. do the units of
        input/output parameters match those for the interfacing system?

-   Does the FSW correctly implement required processing algorithms?

-   Is the FSW sufficiently usable from the point of view of the
    scientists, operations staff, or other end users of the mission?

## 6.3 Heritage/Reused Software Review

Prior to the code inspection, the DTL determines if some FSW code
qualifies as heritage code (acquired from a previous development effort,
with very few or no changes.) Assuming that code is heritage, the code
inspection effort may be less rigorous, but should still include, at a
minimum:

-   Review of approved DCRs applied to the code (Note: All changes
    should be implemented through DCRs. Changes without a DCR will not
    be accepted), including:

    -   Modules that are changed.

    -   Tables that are changed.

    -   FSW code (in context) that is added, deleted (from modules) or
        modified

-   Interfaces from the heritage FSW to other FSW components

The DTL will determine the extent to which heritage code will be subject
to review. At a minimum, interfaces to FSW should be reviewed to ensure
they function in the new environment. Modifications to heritage software
are subject to the normal inspection process. Some assurance should also
be offered that the heritage code is entirely compatible with the
current development environment, including current hardware and
compilers.

## 6.4. Auto-Generated Code Review

Automatically generated code shall also be reviewed, at least once, for
any possible issues. The code cannot be changed but will have to be
regenerated in case there are issues. There may be initialization
scripts, tool configuration GUI/scripts, etc. It may be necessary to
have access to the tool GUI during the inspection to know what is stored
with the tool.

# 7.0 Decorum

It is important that the FSW inspection remain a professional
environment during which common courtesy and personal regard govern the
identification of defects and concerns. The reviewers should focus on
the FSW code for its capability to meet the stated functional,
interface, and performance requirements, and its compliance with stated
design and coding practices. It is reasonable to point to style and code
that provide ready and apparent gains in performance, functionality,
maintainability, and readability. Reviewers can state these factors,
like all others, in a tactful and respectful manner. Disrespectful
approaches do not engender continued teamwork and should not be
tolerated.

This review shall not be refocused from its stated purpose and format to
accommodate inexperienced staff attending for training value.

# 8.0 Follow-up

The recorder will provide the Code Inspection Log Form with the compiled
list of necessary changes to the moderator; the moderator will review
the list, make changes as necessary, and present the list of necessary
changes to the author (and cc: the inspection team) within 2 days
following the inspection, or post it on the CM system. The author and
moderator must then negotiate a deadline for change implementation --
typically within 2 weeks after the author receives the list of necessary
changes.

Once the author has made the necessary changes, he/she updates the Code
Inspection Log Form and delivers the changes to the moderator in order
for the moderator to sign off that all changes are made and all action
items have been closed. The moderator must review each fix to make sure
that the change adequately closes the problem and does not introduce any
new errors. The author ensures that the changes are incorporated through
the FSW CM system.

# Appendix A - Sample Inspection Log and Participants Forms

The forms in this Appendix are samples of the kind of forms that should
be used to capture inspection metrics. Check the FSB Standards web page
for templates.

Code Inspection Log Form

> **Inspected Product:
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_**

  --------- ---------- ------------------- ------------- -------------- ------------------------- ------------
  **No.**   **Line     **Defect/Action**   **Affected    **Assignee**   **Resolution/Comments**   **Status**
            Number**                       Artifacts**                                            

                       **File Name**                     ** **                                    ** **

  **1**                                                                                            

  **2**                                                                                           

  **3**                                                                                           

  **4**                                                                                           

                       **File Name**                     ** **                                    ** **

                                                                                                  

                                                                                                  

                                                                                                  

                                                                                                  

                       **General**                                                                ** **

                                                                                                  

                                                                                                  
  --------- ---------- ------------------- ------------- -------------- ------------------------- ------------

# Explanation of fields on the Code Inspection Log Form:

**Defects/Actions**: The defect or concern should be expressed in terms
of a clear problem statement that can be addressed by one or more
specific actions.

**Line Number:** Line Number within the file referenced.

**Affected Artifacts**: Generally "Code." Select one or more from
"Code," "Design," "Requirement," "Algorithm," or "ICD"

**Assignee:** Typically the issue is assigned to the code author for
resolution. Some action items, e.g., related to ICD or algorithm, may
need to be assigned to others

**Resolution/Comments:** This area is completed as part of the issue
resolution. If a DCR is generated (or used) to address the defect or
concern provide the DCR number

**Status:** Use "Completed" when issue is resolved. If the issue cannot
be resolved comments use "Not Completed" and add appropriate comments in
Resolution/Comments

**File Name:** Name of the file inspected. Include it on a separate row

**General:** Include issues or actions not specific to a file below this
line

Code Inspection Participants Form

> **Inspected Product:
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**
>
> **Date/Time:
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

  --------- ------------------------------ ------------------ ----------- -----------
  **No.**   **Name**                       **Role**           **Hours**   **Phone**

            **Required Participants**                                     

  1                                        *moderator*                    

  2                                        *author*                       

  3                                        *recorder*                     

  4                                                                       

  5                                                                       

  6                                                                       

            **Invited Participants**                                      

  7                                                                       

  8                                                                       

  9                                                                       

  10                                                                      

  11                                                                      

  12                                                                      

  13                                                                      

  14                                                                      

  15                                                                      

                                                                          

            **Subtotal Hours (prior to                        **0**       
            meeting)**                                                    

            Meeting Length (Hours)                                        

            Number of Participants                                        

            Staff Hours Expended for                          0           
            Inspection Meeting                                            

                                                                          

            **Total Staff Time Expended                       0           
            (Hours)**                                                     
  --------- ------------------------------ ------------------ ----------- -----------

# Explanation of fields on the Code Inspection Participants Sheet:

**Participants** -- Populate these fields for each inspection
participant.

-   **No.:** Incrementing number for participants on this list. Note
    that the first three lines are for the moderator, author, and
    recorder.

-   **Name:** Participants first and last name.

-   **Role:** The participant's established role consistent with the
    definitions in this document, e.g. moderator, Test Team Lead, DTL,
    H/W Subsystem, Operations Staff, etc

-   **Hours:** List the total number of hours the participant has
    expended on this effort prior to this meeting.

-   **Phone Number/Ext**: Participant's Phone number and/or extension.

**Subtotals and Totals**

-   **Subtotal Hours (prior to meeting):** Calculate the total number of
    hours the participants expended on this inspection prior to this
    inspection meeting. (Can be automatically computed.)

-   **Meeting Length (hours):** Document the length of the inspection
    meeting.

-   **Number of Participants:** Calculate the total number of meeting
    participants.

-   **Staff Hours Expended for Inspection Meeting**: Total staff-hours
    spent during this inspection meeting. Multiply the total number of
    participants by the length of the meeting. (Can be automatically
    computed.)

-   **Total Staff Time Expended (Hours):** The total staff hours
    expended for this inspection. Add the Subtotal Hours (prior to
    meeting) and the Staff Hours Expended for Inspection. (Can be
    automatically computed.)