NPM RSE Project

--- title: NPM RSE Project tags: rse-projects --- # RSE Project Hackpad - NPM Feature addition ## Project Summary ## Key details - Lead RSE: Alex Coleman - Lead Contact: Victoria Jenneson - Start date: TBC - Number of RSE days: 6 ## Key links - Project GitHub repository: https://github.com/Leeds-CDRC/NPM-Calculator - Project documentation: - Project RSE project board (internal): https://github.com/ARCLeeds/rse-inbound-projects/issues/6 ### Development process This section aims to provide a broad overview of processes for aligning the development process with requirements. #### Code review overview Ensuring code developed during this time is reviewed by others is crucial to ensure it's maintainability and correctness. However, due to the nature of this project being feature development code review is not required at every stage. Therefore, code review will be organised around the following principles: - All pull requests to the `develop` branch will require a code review from at least one other person - Pull requests to `main` will only be for major components of the feature - The aims of code review will be: - To ensure correctness - To ensure documentation (both inline and additional documentation files) are understandable - To ensure changes are justified under the terms of the project #### Deployment overview At present the NPM calculator is deployed at https://npmcalculator.cdrc.ac.uk/ This is a live, production application that we want to mitigate any downtime or interference with over the course of the project therefore: - No deploying to production until final acceptance criteria are met - Use of a dev deployment environment may be used - If any changes to deployment specification will be tested and confirmed in an alternate repository - Steps to ensure the ability to roll back to the current production version of the app will be determined ahead of any update The app is currently deployed automatically through a GitHub actions CI/CD pipeline that interfaces directly with Azure for any commits to the #### Acceptance criteria To help confirm the acceptance of this project it's important we define concrete acceptance criteria. These should relate closely to a series of user stories that describe how a user will utilise the application/feature under development. We can use the Given-When-Then format to define acceptance tests that relate to a scenario: #### Scenario: User has a pre-existing dataframe of food data and wants to test on NPM app Potentially out of scope, addressed alternatively by scenario 13 #### Scenario 1: User uploads data with weird character encoding in their table, app does not run * Given: A user with data containing invalid characters * When: User uploads this to NPM calculator * Then: User is presented with an editable table * And: Data validation highlights errors * Then: User can correct errors before submission #### Scenario 2: User uploads data that contains missing values (in the Energy value, total sugar, saturated fat, fibre (g), protein, or fruit veg nuts fields) * Given: A user uploads data that contains missing values they do not have access * When: The user calculates the score * Then: The calculator defaults NULL to 0, calculates the score for the product but includes a warning (that specifies where NULL is) #### Scenario 3: User uploadds data that contains missing values in the Product Name field * Given: A user uploads data that contains missing values * When: The user calculates the score * Then: The calculator creates a unique product identifier for the product and shows a warning (that specifies where product IDs are NULL) #### Scenario 4: User uploads data that contains missing values in the Brand field * Given: A user uploads data that contains missing values * When: The user calculates the score * Then: The calculator calculates the score and no additional warning information is shown #### Scenario 5: User uploads data that contains missing values in the HFSS legislation category field * Given: A user uploads data that contains missing values * When: The user calculates the score * Then: The calculator calculates the score but cannot give any HFSS 'in scope/not in scope' advisory information. Instead a warning message is shown (saying HFSS status could not be assessed) #### Scenario 6: User uploads data that contains missing values in the 'Type (Food/Drink)' column * Given: A user uploads data that contains missing values * When: The user calculates the score * Then: The score is calculated but a Pass/Fail status is not shown. Instead, a warning message is shown (saying Pass/Fail cannot be assessed) #### Scenario 7: User uploads data that contains missing values in the Weight/volume units field * Given: A user uploads data that contains missing values * When: The user calculates the score * Then: The calculator assumes the unit is grams, and no specific gravity conversion is applied. Instead, an advice message is shown (advising that weight is assumed to be in grams) #### Scenario 8: User uploads data that contains missing values in the Product weight/volume field * Given: A user uploads data that contains missing values * When: The user calculates the score * Then: The the weight is assumed to be 100g and this is used as the denominator to calculate all nutrient density values. The score is generated on this basis and an advice message is shown (advising that nutrient values were assumed to have been provided per 100g of product) #### Scenario 9: User uploads data that contains missing values in the Energy unit (kcal/KJ) field * Given: A user uploads data that contains missing values * When: The user calculates the score * Then: Energy is assumed to have been provided in kcal and the score is generated on this basis. The user sees an advice message explaining the assumption. #### Scenario 10: User uploads data that contains missing values in the Sodium field * Given: A user uploads data that contains missing values * When: The user calculates the score * If: The salt field contains a valid entry * Then: The salt value is used to calculate salt/sodium score * If: The salt field is also NULL * Then: The sodium value is assumed to be zero - the score is generated and the user sees a warning message (highlighting NULLs) #### Scenario 11: User uploads data that contains missing values in the Salt field * Given: A user uploads data that contains missing values * When: The user calculates the score * If: The sodium field contains a valid entry * Then: The sodium value is used to calculate the salt/sodium score * If: The sodium field is also NULL * Then: The salt value is assumed to be zero - the score is generated and the user sees a warning message (highlight NULLs) #### Scenario 12: User uploads data that contains missing values in the Fibre unit (AOAC/NSP) field * Given: A user uploads data that contains missing values * When: The user calculates the score * Then: The fibre value is assumed to be given in AOAC unit and the score is generated on that basis - the user sees an advice message (advising that the AOAC fibre assumption has been made) #### Scenario 13: User wants to know what format the data they need to provide to the app is * Given: A user has existing data and wants to test it against NPM * When: The user vists NPM site * Then: They can download a template NPM calculator format file in the correct format (available in .csv and .xlsx) #### Scenario 14: User uploads a table of 5 items * Given: A user uploads a table of 5 items * When: The user calculates scores * Then: User is presented with results with a graph per item #### Scenario 15: User uploads a table of greater than 5 items * Given: A user uploads a table of greater than 5 items * When: The user calculates scores * Then: User is presented with results in a summary graph format showing different food categories and pass, fail & in-scope status * And: if items don't have categories * Then: Show a summary graph of everything/unassigned category #### Scenario 16: User wants to download output table * Given: A user has uploaded data and calculated scores on the app * When: The user wants to download the calculated scores and selects Download and the corresponding `Format` radio button * Then: The browser downloads the results in the specified format. The output data corresponds to the input dataframe with new score, pass/fail, notes column merged by item name #### Scenario 17: User has a list of products they wish to test on the NPM app * Given: List is in a .csv or excel format with the columns X, X and X * When: The user uploads this to NPM and clicks Calculate Score * Then: NPM calculator returns a table listing products and scores, pass/fail status, HFSS status, and any warnings/assumptions * And: User clicks Download button * When: User has selected a format radio button (.csv or .xlsx) * Then: Browser downloads presented table as specified file type #### Scenario 18: User uploads data for a food product where the volume is specified in ml * Given: User uploads data for a food product where the volume is specified in ml * When: The user calculates the score * If: The user has specified the type of food sold in ml * Then: That type of food will be used to assign the specific gravity conversion to be applied * And: The weight of the food in grams is used to calculate nutrient densities for the overall score * If: The user has not specified the food type * Then: The specific gravity will be assumed as 1 and no conversion will be applied. * And: The score will be calculated and an advice note will show (saying no specific gravity conversion was applied) Specifying a number of these scenarios as our project acceptance tests are a useful aid for development and ensuring the end product is ready for deployment. Only once all acceptance tests are met is the app ready for deployment.