Describe the engineering process to be used for the design, development, and release of the software, its deployments and associated outreach to the end-user community, and an evaluation plan that involves end users.
A voting systems is developed and integrated into the CSDMS community content management platform such that community members can express their opinion whether or not to incorporate a module into the CMT. Community members have to login to the content management platform, select a model that is not yet incorporated into the CMT and provide their vote rating from 0 to 1, with 0 no need to incorporate a model and 1 as being a high priority to incorporate a model into the CMT. Voting results are displayed for everybody, but the voting itself is anonymous. An internal database on the background keeps track of each members voting such that members can only vote once for a specific model but they can change their vote throughout the voting process up to the point where the CSDMS Integration Facility decides to incorporate a model.
Phases of development. Each phase results in a software release.
The CSDMS project has idenified three main milestones that moves a model from a standalone piece of code to a coupleable component that is freely available to the community. Each development phase is marked with a software release. The three phases deploy the model as a standalone executable, a CCA-wrapped component, and as a fully coupleable component.
While CSDMS has concentrated on the development of models, we will extend this engineering cycle to provide community software that aids model development, testing, and usability. Types of software we will release following this engineering process are:
NOTE: What about service components? Same process?
NOTE: Tools to test for CMI compliance.
Before a piece of software is released to the community as a standalone executatbe it must first provide the following: metatdata, source code, input and output data, list of resources required to compile on the target platform(s). The software elements this phase generates may or may not go on to be deployed as components within the CSDMS modeling framework (phases 2 and 3).
Metadata. CSDMS has developed a model questionaire that must be completed before a model or tool is contributed to its software library. This metadata provides:
We will continue to require this metadata for code submitted to the software library. Requested metadata will be adapted to fit with new types of software (standalone/couplable model components, service components, etc.) being submitted.
Source code. Software source code muse be freely available to the community. CSDMS provides a subversion repository for each software element for developers to use and also distriute software as source-code release packages.
Input/output data. Where possible, software must be submitted with sample input and output data. These data are provided as a way to demonstrate what the software element does, as well as for a basis of regression tests.
Compilation. Source code must come with specific compilation instructions, and must compile on its target platforms for it to be made available in the software library.
Phase 2 of the CSDMS development path takes a software element that has completed phase 1 and turns it into a component that is able to be instantiated and run with the CSDMS modeling framework. For this phase a software element must: expose an IRF interface, be wrapped as a CCA component or class, and provide content description for a graphical user interface, template input and output files, documentation, and sample BLD files, and pass testing procedures.
IRF interface. Models that wish to become components must expose an Initialize, Run, Finalize (IRF) interface. Other types of software, for which this interface is not appropriate, must describe the interface they implement.
CCA component/class. Software to must be wrapped as a CCA component or class so that it can communicate with the CSDMS modeling framework.
Graphical user interface. An XML description of the content of a graphical user interface for the component.
Template input/output files. Input and/or output template files (as appropriate) for each component that will be filled with data gathered from the end user (from a GUI, for example).
Documentation. All components must adequately document how a user is to interact with the component and what the component does.
BLD files. Components intended for use within the CMT, must provide example BLD files. The BLD files will instantiate the component and configure it for an example simulation. Multiple BLD files will be provided to demonstrate the full functionality of the component.
Testing. All components will be adequately tested. The input and output of a component will be compared to similar input and output from the testing stage from phase 1. Phase 2 testing will be of the component itself, the underlying software element will have been conducted in phase 1.
Phase 3 of the CSDMS development path extends a standalone component to one that couples with other components. To complete phase 3, a phase 2 component will: expose a getter/setter interface, provide coupling documentation, and sample BLD files, and pass testing procedures.
Getter/setter interface. The phase 3 component will implement the full component modeling interface (CMI) by extending its phase 2 interface implementation to include getters and/or setters (as appropriate).
Documentation. All coupleable components will provide documentation that describe their use as it relates to interacting with other components.
BLD files. Components intended to be coupled within the CMT, will provide example BLD files. The BLD files will instantiate the component, link it with another component(s), and configure the combination for an example simulation. Multiple BLD files will be provided to demonstrate a range of functionality.
Testing. All coupled components will be adequately tested. Component ensembles will be validated and tested by a working group of specialists.
Software will be deployed for use both on a community shared resource (such as the CSDMS HPC cluster), or on a user’s personal computer.
Access to the CSDMS high-performance computing cluster is freely available to community members. Users will be able to access, and run generated software either through command-line tools or by running the CMT client application. The complete CSDMS/CCA toolchain will be deployed on other clusters as well. This allows users a choice of where they run/develop code, and provides hardware stability (less downtime) by physically distributing resources. Do we actually have buy-in from anyone? Can we get a letter? What about Janus?
Individual software elements (models, tools, etc) will also be deployed for use on individual computers.
Determine the resources at end-user site? support? Documentation
Software configuration, compilation, and installation will be managed with CMake. Software builds and testing will be reported through a dashboard managed with CDash.
Software elements will use Trac for project management and issue-tracking. End users will be able to submit tickets to report bugs or feature requests, view/edit software documentation through a wiki, view svn repositories, timelines, and project milestones.
Not too sure about this but needs to involve end users. Who are the end users?
Tests will be made public. More successful tests, more stars. Software is reviewed by a working group of specialists.