noaa-fims / fims-planning Goto Github PK

Make presentation for 3/18 FIMS meeting

• Define the key terms (requirements gathering, prioritization, scoping, costing, milestones)
• Identify requirements gathering timeline and steps. Share the requirements template.
• Agenda for next meeting (will use mind mapping to define themes or sub groups that can go off and do requirements gathering)

https://docs.google.com/spreadsheets/d/1X8LRx2toisPTLToXgJ6Slk6SaeGe1PQlYAakZnjqarA/edit?usp=sharing

https://docs.google.com/document/d/1eAZEDXKKdmFs0j6CgfQCUvQD1OyUJioD/edit?rtpof=true

This came up in discussions for the software design spec #20 - we want to avoid bloat so we should only add features if they are a documented best practice. We need some principles for what constitutes a best practice. Some ideas:

1. A research study (ideally >1) has proven this is the most accurate approach.
2. This feature is implemented in a tactical stock assessment modeling platform where >1 real world assessments use it
3. This feature follows sound statistical principles.

put together agenda and deck for 3/31

https://docs.google.com/document/d/1iSEhJqcpSD269QdABeDE4aBZGqGcBrIrLnS7eMkSYv0/edit

Complete first draft of this specification by Dec 3RD

https://docs.google.com/spreadsheets/d/1Hqj9xPMCbzEXCF8GqFaRiaKdZ54fhU8HTUZslzSsZJQ/edit

Take requirements spreadsheet & flesh out goals etc to fill the rest of requirements doc template

I think the I/O file type and structure is worth some thought. E.g., if we use TMB do we have ASCII files that get parsed in R, or specify things directly in R? Likewise for outputs. As an SS user I almost never look at output files b/c they get read in by r4ss. So can we skip that step? It seems unwieldly for a TMB model to create the output in R, write to file, then read it back in for analysis.

Would be curious to hear @timjmiller opinion on this with his experience with WHAM.

Some thoughts on test-driven development based on the r4MAS testing work. It would be great to create unit tests, functional tests, and integrated tests to introduce as many automated checks as possible to validate models before the models are fully developed. Once those test cases are created, they can be added to a continuous integration tool (e.g. GitHub Action) so that every time a commit or a pull request is merged in on GitHub, this suite of tests is run. It may have overlap with the collaborative workflow issue #17 if we need to create testing procedure template.

This fishsad - Fisheries Stock Assessment Data repository is used to store assessment input and output data for cross-model testing. The assessment data repository can be linked with another repository, which contains functions that facilitate the conversion of stock assessment input files from one framework to another (e.g. saconvert). Would be curious to hear opinions from others on setting up FIMS testing framework.

After software design specification is drafted will begin work on the test specification

• Forecasting

Complete draft guidance on how to work collaboratively to develop the FIMS project in time for milestone start

For anyone interested in contributing to the FIMS software platform investigation, comment below or start an issue in the FIMS-software repo.

https://docs.google.com/spreadsheets/d/1OxIxFAGimkePcXHVK2sWtnuDC_tq-qYOR_HEzykufDc/edit?usp=sharing

To me, I think it seems important to set up FIMS in a way that makes the collaborative coding/contributing experience as painless as possible. I think this is addressed in the developer's experience requirements, but to me it really seems non-negotiable and something that needs to be set up at the begining of the project.

I think it would make sense to form an investigation group that could start brainstorming how to set up the tooling and collaborative workflow so that everyone involved in FIMS can successfully contribute, whether they are contributing ideas, documentation, code, code reviews, or something else.

This idea has some overlap with architecture/software platform and testing also - not sure if these ideas should just be addressed within those groups instead?

File I/O specification needs to be specified after software & in parallel with test specification

The 1-2 scale is confusing to the groups. For now, we are going with high/low and will revisit a quantitative prioritization method later on.

Define planning milestone and timeline

@msupernaw @Bai-Li-NOAA @ChristineStawitz-NOAA and @HaleyOleynik-NOAA started the mind map - have fully integrated SEFSC and PIFSC requirements.

https://docs.google.com/spreadsheets/d/173ZszPcibwA36hPmscwvLojSrqTkrhWyU2ot5LFax_s/edit#gid=0