Astrodynamic Standards Development, Test and Support
Astrodynamic Standards Development, Test and Support
DSoft Technology has played an integral role in several parts of the Air Force Space Command Standardized Astrodynamic Algorithms (SAA) program.
DSoft provides support to AFSPC in improving aspects of SAA source code, ranging from minor bug fixes to incorporating entirely new functionalities. DSoft created and maintains a SharePoint site containing a list of open issues with the source code, including those reported by users and those identified by DSoft during development. The site serves as a collaborative portal that can be accessed both by developers at DSoft and at AFPSC. Items on this list are prioritized according to severity of the issue, which streamlines the development process by providing focus as to which items must be resolved before a given release can be delivered. With guidance as needed from AFSPC and other SMEs, DSoft updates the source code to resolve open issues and conducts tests to verify success before marking the item as closed and ready to be included in the newest SAA version.
SAA Unit Testing
DSoft Technology provides support to AFSPC in conducting unit testing, V&V testing and documentation for the release of new SAA versions. DSoft utilizes Microsoft Visual Studio's built-in unit testing framework to test the SAA DLLs and associated language wrappers. The creation of unit tests for each SAA DLL was assigned to subject matter experts (SMEs). DSoft worked with these SMEs, often in pair-programming situations, providing the SMEs with assistance in unit testing strategies, framework expertise and Python syntax. This collaboration allowed the SMEs to create quality unit tests without being burdened by programming and framework issues that are not related to their core mission. The resulting unit tests have already identified some long-standing issues with the SAA code and will provide a lasting benefit to the SAA program by allowing the unit tests to quickly identify many types of issues before the more labor intensive verification and validation (V&V) tests are run.
DSoft Technology revised and updated the documentation provided to users as part of the SAA distribution. In previous versions, the documentation for each SAA module was split into two parts. The API documentation was provided as compiled help files (CHM) which were generated automatically from the SAA source code. Microsoft Word documents (DOC) were also provided which included explanatory information, use cases, and data format descriptions. The DOC files also included duplicate API documentation with added examples and remarks.
DSoft Technology revised the documentation structure to consolidate all the documentation in the CHM files. The API remarks and examples from the DOC files were moved into specially-formatted comments in the SAA source code so they could be extracted as part of generating the CHM version of the API documentation. This eliminated the need for the redundant DOC API documentation, eliminated the possibility that the two versions of API documentation would differ, and put the remarks and examples in the source code where they will be most easily maintained by the programmers as changes are made. The additional content provided in the DOC files was converted to GhostDoc custom content pages and included in the CHM files. This effort puts the documentation in a format more easily maintained by AFSPC and provides SAA users with a single source of documentation for each module.
SAA V&V Testing
DSoft Technology built a custom Automated Testing Framework (ATF) to perform verification and validation (V&V) testing of SAA DLLs. The ATF is built using the Space Analysis Integration Toolkit (SAINTTM) to run input files and compare the resulting output files against baseline output files. The comparison is done by utilizing VERDICT which is an AFSPC developed tool to compare files line by line. ATF is able to set up multiple test runs of the different SAA DLLs and run all these test cases concurrently and get instant pass/fail feedback. ATF can be run both as a console and GUI application. The console version is used in a continuous build process using TeamCity. The build process takes the latest SAA DLLs, generates C# wrappers, runs all unit tests, provides code coverage based on the unit tests, runs all V&V tests using ATF, generates documentation (CHM) and produces WIN & Linux (32 & 64 bit) packages for each SAA DLL.
Standardized Astrodynamic Algorithms Library Continuous Integration Process
DSoft Technology created and maintains a continuous integration (CI) process to automate building, testing, creating documentation, and packaging the Standardized Astrodynamic Algorithms Library (SAAL). The CI process includes building the SAAL dynamic link libraries (DLLs) on four platforms (Windows and Linux, 32- and 64-bit), running comprehensive unit tests, running V&V tests, creating up-to-date documentation from source code and auxiliary content, and creating packages for 15 different modules that properly include all dependencies, test code, documentation, and related files. The SAAL CI process has improved the efficiency and quality of the SAAL program by providing reliable on-demand package creation with all assets tested and configured consistently.
DSoft Technology created the Public Astrodynamic Algorithm Distribution Site (PAADS) website as a means of providing SAA information and access to the request process to a wider audience at a lower cost. DSoft had previously created and maintains the Space/Cyberspace Analysis Resource Portal (SARP) website, which automates the SAA request process. However, access to that site is only available on the Air Force (AF) Non-Secure Internet Protocol Router Network (NIPRNet). Users without access to NIPRNet using a Common Access Card (CAC) have submitted requests via email and SARP administrators manually enter those requests into SARP - a process that was error-prone and time-consuming, resulting in delayed delivery of software to the end customer. The PAADS website was designed to alleviate this issue by providing a publically-accessible website that includes the complete SAA request wizard process and an automated method for importing these requests into SARP.
Users complete a multi-step wizard designed to collect all the information required for an SAA request, and the SARP website provides the administrators with tools to advance each request through the workflow process to approve, authorize, and ultimately distribute requested software to users. The PAADS site collects all the information required before the submission process starts and eliminates the manual entry of the request data in SARP. In order to protect the personally-identifiable information (PII) of requestors using PAADS, the request data is encrypted with public-key encryption in a format that allows the SARP administrators to automatically decrypt and import the requests into SARP. The PAADS website promises to make SAA requests originating from outside AF networks much easier on both the requestors and the SARP administrators, facilitating a wider distribution of SAA to interested users.
In addition to the SAA request wizard, the PAADS site includes a frequently-asked questions (FAQ) section that provides a growing repository for information about the use of SAA modules. The FAQ is being created both with documentation and use cases created by SAA maintainers and with real questions submitted by SAA users. The FAQ provides SAA users with a convenient means of finding answers to questions about SAA implementations and removes the burden on AFSPC personnel to continually address the same issues raised by different users.