Collection Spreadsheets

*** Starting with NPR 7150.2C, the following metrics collection instructions now apply to all Class D software also. ***

In accordance with LPR 7150.2B, each project developing software that is Class A, Class B, Class C, or safety-critical must provide software metrics data to the SEPG.  The SEPG has developed a pair of Excel spreadsheets to facilitate data collection:

Metrics Collection Spreadsheet for Development Projects

Metrics Collection Spreadsheet for Maintenance Projects

The Development Project Metrics spreadsheet is for projects developing or upgrading a software product to a defined set of requirements under a budget and schedule.  The Maintenance Project Metrics spreadsheet is for projects performing on-demand fixes or enhancements to an existing software product in response to change requests or problem reports; maintenance projects typically have a budgeted level of effort.  A project that begins in development (using the Development Project Metrics spreadsheet) will transition to maintenance (and use the Maintenance Project Metrics spreadsheet) after the software has been accepted for its intended use.  If you have a question on which spreadsheet to use, contact the SEPG Representative for your directorate.

Submitting metrics data is not a one time activity.  Each tab (i.e., worksheet) of the spreadsheets (i.e., workbook) is completed and submitted at different measurement milestones in the project.  These milestones are:

After completing each worksheet of the workbook, the NASA Software Lead (see LPR 7150.2B section 2.1.2) sends the workbook to the e-mail address larc-dl-sepg@mail.nasa.gov.  The NASA Software Lead should give the file a name of the form <Development | Maintenance>_Project_Metrics_<project name>.xlsx where <project name> is the name of the project.

Frequently Asked Questions (FAQ)

Does each software product need to be reported on a separate spreadsheet?
Can I submit one spreadsheet for multiple, but related software activities performed by the same pool of developers such as all the software maintenance performed for a facility?

LPR 7150.2 requires that  data be submitted for each project.  A project may develop or maintain multiple software products.  For the purpose of this requirement, a project is any collection of software activities managed together under the same organizational structure, budget, and software management plan.  A project portfolio (see LPR 7150.2B section 2.7) can have such a common management approach and be treated as a single reportable entity for software metrics.  For example, all software maintenance performed for a facility can be organized as a project portfolio.  In other cases, where the various software activities are distinctly managed but the organization has good reason to bundle them for metrics reporting, this bundling can be done via tailoring and approved by the designated Technical Authority(ies) (see LPR 7150.2B section 3).

What do I do if the software language or development tool is not on the drop down list for Primary Language?

Just type in the language or tool that you are using.  The field will accept custom entries.  If the SEPG sees enough custom entries for a language or tool, then it may be added to the drop down list in a future revision of the workbook.

What do I enter for software size if my language or tool isn’t compatible with counting lines of code?

The software size entries consist of two fields, a count field and a units field.  The units field has only two entries in its drop down list, lines of code (LOC) or functions points (FPs).  However, the units field will accept custom entries.  Simply type in whatever unit is convenient for you to count and is somewhat representative of the amount of work that went into the software.  Examples of alternative units include bytes (in the user files created by the tool or in the final executable), classes, functions or subroutines, blocks (e.g., Simulink), macros, controls or widgets (e.g., for Graphical User Interfaces), rungs, cells, fields (e.g., for data input applications), or files.

When providing planned or actual costs for software, how should the project estimate the cost of software that is included with purchased hardware (or other non-software products); e.g.. board support packages, drivers, interface libraries, or utilities for device diagnostics, device configuration, or device monitoring.  Should we guess what portion of the purchase price is represented by the software? Do we include the full purchase price? Or, do we assume the software has zero cost?

The project should either exclude or include the full cost of the purchase. The choice depends on how the project decides to bookkeep the purchase. For example, a project building a new avionics system may bookkeep the purchase of all boards and sensors under its hardware engineering activity. Though the purchase includes driver and board support software, the full cost of the purchase is assigned to the hardware engineering task, with no cost assigned to the software engineering task. On the other hand, a project that is adding support for a new peripheral device (with software drivers) to a computing system may perform little to no hardware engineering, and therefore assigns the full cost of the device to the software engineering task.