Skip to content

Milestones

List view

  • Task 7: User Guide and Documentation

    Once implementation and testing has been completed, the software user guide will be written and compiled. Versions of this will be made available as pdfs, and on any online Wiki or other documentation store. The sphinx compiled documentation will be reviewed and modified, to make sure that its coverage is comprehensive, explanative, and readable.

    Overdue by 6 year(s)
    •
    Due by June 26, 2020
    •23/23 issues closed
    100% complete0 open23 closed

  • Task 6: Verification and Testing

    Under this task, system verification and testing will be performed. This will involve the creation of a test plan, that will be provided to Dstl for review at the end of Sprint 2. A test report will be produced during sprint 3 detailing the results of verification and validation testing, and this will be delivered at the end of sprint 3. Starting even before the formal test phase, a series of automated system tests will be developed that verify that all elements of the SoR have been met. The testing and results of these system tests will inform the contents of the test plan/report. In the case of the well-mixed and eddy diffusion models, these tests will involve an evaluation of exact solutions of the equations, and the verification tests ascertain whether the output plots and data implement the functions specified in the SoR. If a more involved implicit model is implemented as one of the diffusion models, then a more elaborate series of validation steps will be taken. For example, comparison of outputs against wellestablished CFD toolkit, such as OpenFOAM, could provide supporting evidence of the accuracy of particular dispersion models. In addition, any experimental results provided by Dstl can be incorporated into the test regime to provide automated validation.

    Overdue by 6 year(s)
    •
    Due by June 11, 2020
    •40/40 issues closed
    100% complete0 open40 closed

  • Task 5: Command Line Interface

    Task 5 of the ITT Response - Create the command line interface module. Implement the command line interface using click. This milestone should include all Unit Tests and doc strings.

    Overdue by 6 year(s)
    •
    Due by May 15, 2020
    •9/9 issues closed
    100% complete0 open9 closed

  • Task 4: Data Analysis Module

    Task 2 of the ITT Response - Create the Data Analysis Module. This should fulfil all requirements set out in the Specification of requirements. This includes unit tests and doc strings.

    Overdue by 6 year(s)
    •
    Due by May 13, 2020
    •20/20 issues closed
    100% complete0 open20 closed

  • Task 3: Data Storage Module

    Task 3 of the ITT Response - Create the data storage module. This will include writing the output of the equations solver module to disk, if needed. This should be in plain text format (JSON). This includes unit tests and doc strings.

    Overdue by 6 year(s)
    •
    Due by May 6, 2020
    •5/5 issues closed
    100% complete0 open5 closed

  • Task 2 - Equations Solver Module

    Task 2 of the ITT Response - Create the equations solver module. This should implement both the eddy diffusion model and well mixed models. This milestone should include all Unit Tests and doc strings.

    Overdue by 6 year(s)
    •
    Due by May 1, 2020
    •13/13 issues closed
    100% complete0 open13 closed

  • Task 1 - Input File Parsing Module

    Task 1 of the ITT Response - Create the config file parser module. We propose using JavaScript Object Notation (JSON) format for the implementation of the input file requirement specified in the SoR. The benefit of using the JSON format are as follows • JSON parsing - parsing capability exists as a python standard library in the form of the [json] module. • JSON as a data interchange format – JSON is now the de facto language of REST APIs, allowing for easy integration of any network capability, should the need arise. • Intuitive structure – The JSON format naturally fits the configuration file format, with its selfsimilar nature. Furthermore, Riskaware has internal modules for adding functionality such as file scheme definitions, with type and value verification at the point of parsing which reduces the need for addressing exception handling in other parts of the code base. Should other restrictions or requirements become apparent in the future the preclude the use of JSON, alternative methods will be considered, up to and including a bespoke implementation to meet the client’s needs.. Completion of this mile stone will include unit tests and doc strings.

    Overdue by 6 year(s)
    •
    Due by April 24, 2020
    •17/17 issues closed
    100% complete0 open17 closed