Developers Guide

This document includes some details relevant for developers.

Guidance for Contributors

Below are a few design decision made by the authors, documented for the reference of new contributors:

  • When supplied by or to the user, values with names (e.g., inputs, states, outputs, event_states, event occurance, etc.) should be supplied as dictionaries (or dict-like objects) where they can be referred to by name.

  • Visualize and metrics subpackages shall be independent (i.e., not have any dependencies with the wider package or other subpackages)

  • Limit introduction of new external dependencies, when possible.

  • This is a research tool, so when making a design decision between operational efficiency and usability, generally choose the more usable option

  • Except in the most extreme cases, maintain backwards compatibility for the convenience of existing users

    • If a feature is to be removed, mark it as depreciated for at least 2 releases before removing

  • Whenever possible, design so a new feature can be used for any model, interchangably.

  • Whenever possible, UncertainData types, state estimators, and predictors should be interchangable

  • Demonstrate common use cases as an example.

  • Every feature should be demonstrated in an example

    • The most commonly used features should be demonstrated in the tutorial

Branching Strategy

Our project is following the git strategy described here. Details specific to each branch are described below.

master: Every merge into the master branch is done using a pull request (never commiting directly), is assigned a release number, and must comply with the release checklist. The release checklist is a software assurance tool.

dev: Every merge into the dev branch that contains a functional change is done using a pull request (not commiting directly). Every commit should be functional. All unit tests must function before commiting to dev or merging another branch.

Feature Branches: These branches include changes specific to a new feature. Before merging into dev unit tests should all run, tests should be added for the feature, and documentation should be updated, as appropriate.

Release Checklist

  • Code review - all software must be checked by someone other than the author

  • Check that each new feature has a corresponding tests

  • Run unit tests python -m tests

  • Check documents- see if any updates are required

  • Rebuild sphinx documents: sphinx-build sphinx-config/ docs/

  • Write release notes

  • For releases adding new features- ensure that NASA release process has been followed

NPR 7150

This section describes this project’s compliance with the NASA’s NPR 7150 requirements, documented here.

  • Software Classification: Class-E (Research Software)

  • Safety Criticality: Not Safety Critical

Compliance Notation Legend

  • FC: Fully Compliant

  • T: Tailored (Specific tailoring described in mitigation) SWE-121

  • PC: Partially Compliant

  • NC: Not Compliant

  • NA: Not Applicable

Compliance Matrix

SWE #

Description

Compliance

Evidence

033

Assess aquisiton Options

FC

See section below

013

Maintain Software Plans

FC

This document

042

Electronic Accesss to Source

FC

This repo

139

Comply with 7150

FC

This document

121

Tailored Reqs

NA

No tailoring

125

Compliance Matrix

FC

This document

029

Software Classification

FC

This document

022

Software Assurance

FC

This document

205

Safety Cricial Software

FC

See above

023

Safety Critical Reqs

NA

Not safety critical

206

Autogen Software

NA

No autogen

148

Software Catolog

FC

Will be added

156

Perform CyberSecurity Assessment

FC

See section below

Aquisition Options

Assessed, there are some existing prognostics tools, but no general python package that can support model-based prognostics like we need.

Cybersecurity Assessment

Assessed, no significant Cybersecurity concerns were identified- research software.