Developers Guide¶
This document includes some details relevant for developers.
Contents
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.