Developers Guide

This document includes some details relevant for developers.

Installing from a branch

To install the prog_models package from a specific branch. First clone the repository and checkout the branch. Then navigate into the repository directory and use the following command:

pip install -e .

This command installs the prog_models package using the checked-out version.

Contributing

New external (non-NASA or NASA contractor) developers must complete either the organizational or individual Contributor License Agreement (CLA).

Curious about what needs to be done? Have an idea for a new feature? Find a bug? Check out open issues.

Notes for developers

  • The package itself is stored in the src directory

  • Examples are included in the examples/ directory.
    • Examples should cover the major use cases and features. If a major new feature is added, make sure there’s an examples

    • For new examples- add to examples __all__ and example tests (tests/test_examples)

    • Also for new examples- add to getting started page in sphinx_config

    • Examples should include comments explicitly describing each step

  • Tests are included in the tests/ directory
    • Each new feature should have a test. Make sure in PR review

    • Check test coverage to improve completeness

    • For tests- make sure test are quality. They should cover expected input ranges, error handling.

  • Documentation
    • Documentation is autogenerated using sphinx.

    • Configuration is in sphinx_config

    • Documentation is rebuilt on each release

    • On each release, documentation can be seen at nasa.github.io/prog_models

  • GitHub Actions
    • Automated tests are defined in .github

    • Adding tests to required must be done by administrator

  • Template
    • An empty template of a prognostics model is maintained at prog_model_template.py

    • Any changes to the basic model setup should be documented there

  • Dependencies are listed in requirements.txt. In general avoid adding a new dependency

  • A tutorial is included in tutorial.ipynb. This required Juypter Notebooks. All major features should be illustrated here.

  • Legal stuff: All pages should have the following notice on them:

“Copyright © 2021 United States Government as represented by the Administrator of the National Aeronautics and Space Administration. All Rights Reserved.”

Branching Strategy

Our project is following the git strategy described here. Release branches are not required. 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 commit on the dev branch 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.

PR Checklist

  • Each PR into dev or master must be checked by someone on the team other than the author.
    • Reviewer should look for bugs, efficiency, readability, testing, and coverage in examples (if relevant)

  • All tests must be passing

  • All errors from static analysis must be resolved

  • All warnings from static analysis must be reviewed and resolved - if deemed appropirate

  • For merge into master - see Release Checklist below

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

  • Review the template

  • Test the tutorial

  • Check documents- see if any updates are required

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

  • Write release notes

  • Update version number in src/prog_models/__init__.py and setup.py

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

Updating Documentation

Use the following command to update documentation (requires sphinx): .. code-block: bash

sphinx-build sphinx_config docs`

Uploading new version to PyPI

New versions are uploaded upon release (i.e., merge into master). The Release Checklist must be complete prior to release

See here

NPR 7150

NASA software must comply with the requirements enumarated in NPR 7150 <https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2B>. See the NASA Software Engineering and Assurance Handbook <https://swehb.nasa.gov> for more information.

  • 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.