The GMAT project will spend a significant amount of time during our R2017 release development on code cleanup, developer documentation, quality improvements, and refactoring for improved long-term positioning.
- Ensure that GMAT can continue to respond to customer needs as the team grows and evolves
- Improve work-time to perform frequent developer tasks (i.e. new built-in functions, new)
- Improve documentation of key components (developer docs and code comments)
- Ensure key components developed by those planned are documented and code is cleaned up
- Improve ability to add third-party plugins
- Improve system modularity and documentation
- to support re-use of sub-components
- to facilitate exposing of portions of GMAT through an API
- Address high value P2 improvements that often get overlooked
Key Developer Documentation
- (DJC)Document the code so that all methods are documented and no warnings are issued during builds.
- (DJC) If the Doxygen generator identifies missing blocks, fix them (Subheading: Follow the style guide!)
- (DJC) Warnings are being ignored. This is VERY dangerous – let’s clean them up now, and fix them as they occur.
- (DJC) Remove special case code from the Interpreter subsystem and Moderator(SPH)
- (DJC) Modularize libGmatBase into several libraries. The goal here is to fix the circular dependencies in the code, and as a side benefit to make some core components available as libraries. Having GMAT build with one library is okay, IMO, but the cross-dependencies make code maintenance more difficult.
Expansion to the Parameter Subsystem (DSC)
- (DJC) Add an option that does not require multiple inheritance
- (DJC) Add a registration method so that a class can register, rather than needing to create an object. Here's how I think we might do this -- but this doesn't work:
Existing High Value Quality Tickets
Tickets that to be considered for quality improvements should be marked with the JIRA label "Quality". This filter tracks proposed quality improvements.