2024-04-21 - TMA02 Writing

Date: Sunday, April 21, 2024

Work Undertaken Summary

Risks

Time Spent

4.75 TMA02 writing. 2.5 lsepi 2.5hr datatransformer anonymiser 0.25 diagram 0.25 TMA02 writing 4.75hr TMA02 writing

Questions for Tutor

Next work planned

read Embedding equality, diversity and inclusion in your project: 2.1 Responsible innovation | OU online (open.ac.uk) read https://learn2.open.ac.uk/mod/resource/view.php?id=2217347

Raw Notes

TMA Tweaks

1. Change title to be more specific about the output
2. Add table of contents and table of figures
3. Heavily Rewrote Problem Description
4. Add diagram for Client Relationship
5. Update Diagram for incremental creation of documentation
6. Add Diagram for pepper database

Legal, Social Ethical and Professional issues

Stakeholders

1. Myself
2. My employer
   1. Potential damage to reputation
   2. Potential damage to client relationship
3. The client

Cards do not store any special categories of personal data. They do contain names, which will be pseudonymised by the StoryTransformer component. There is a legitimate reason for needing to be able to reverse the process, however for the purposes of this report it is irrelevant and so for OU consumption it will be anonymised.

The inputs or the outputs could contain information that could damage the employer-client relationship, so the inputs and outputs that are shared will be reviewed before release.

Support cards can include personally identifiable information such as names and email addresses. Therefore we will not use support cards in the creation of the documentation.

For the documentation to be useful it needs to be complete and accurate, the information in pepper includes information that the client is not privy to. This includes certain technical details and results of internal discussions which include sensitive information that could affect the client relationship. As a result the documentation that is generated from this information cannot be shared with the client, as it includes information that they do not have the rights to see.

At the moment both myself and the client have equal ease of access to the client visible information stored within pepper. The creation of the documentation that is not shared creates a gap in ease of information retrieval. However as this does not pose risk of harm to the client as the information is still available to them and the speed of access is a benefit to them as it results in shorter turn around time on questions and therefore more efficient use of their support contract time.

The client has consented to the processing of information within pepper, and the ease of access of information being created by this process is no different than a more effective search being implemented within pepper.

Talk about hallucinations, and how they will be caught.

Talk about bias in the model.

Talk about potential risk to my employment, giving up silo-ed knowledge but gaining

Talk about the importance of keeping the data private, e.g. must use local AI.

Talk about scrubbing the names / pii from the user stories prior to running through the AI. Talk about how the names were replaced with gender neutral names to avoid the potential for the names to bias the output.

Legal, Social, Ethical and Professional issues: 2 Working with stakeholders | OU online (open.ac.uk) And also Embedding equality, diversity and inclusion in your project | OU online (open.ac.uk)

and also https://learn2.open.ac.uk/mod/resource/view.php?id=2217347

Answer the questions in here: Legal, Social, Ethical and Professional issues: 4. Asking the right questions | OU online (open.ac.uk)

I need to sign the TMA02 LSEPI Form

KJ email

Email needs to ask for:

1. Permission to access story information from pepper system (DB access kept in cloud)
2. Permission to publish a cut down database schema for the pepper system (IP)
3. Permission to publish both examples of the inputs and outputs, having validated that no sensitive information has been revealed
4. Agreement to be a supervisor to oversee the project ” identifies a gatekeeper/supervisor who will ensure support and logistical advice on the research project while it is conducted.”

Tutor Email

I’m having trouble with the documentation for the LSEPI aspect for my project. There are 3 groups of stakeholders:

1. Myself who is the beneficiary of the project
2. My employer, who owns the rights to the data I am using for the project (with their permission)
3. The client

I will be discussing the impacts to each of the stakeholders but as far as I can see there are only either positive outcomes or risks which will be mitigated with human review.

As far as I can see I only need to ask my employer (not the client) as the employer owns the rights to the data and any harms to the client are being mitigated.

I’ve already asked and received written permission (via slack) from my employer, but for the purposes of the report I want to get the permission in the specific format that is expected.

Specifically I will ask the company directory for:

1. Permission to access story information from ticketing system (read-only DB access)
2. Permission to publish a cut down database schema for the ticketing system (the bits my project needs to integrate with)
3. Permission to publish both examples of the inputs and outputs, having validated that no sensitive information has been revealed
4. Agreement to be a supervisor to oversee the project ” identifies a gatekeeper/supervisor who will ensure support and logistical advice on the research project while it is conducted.”

I am not conducting a survey or interviewing anyone. I am able to specify desired outcome and judge the result independently.

From our previous discussions I was under the impression that a documented email would be sufficient regarding proof of the above permission. From the resources on Student home it looks like I may be expected to create and get a signed consent form and participant information sheet.

Can you please confirm if it should be an email or using the forms?

Many thanks, Luke

Anonymisation rule

{  
  "Rules": [
    {
      "Regex": "(luke(\\.| )?foreman)|(\\bLuke)|(\\bLF\\b)",
      "Replacement": "Lucy"
    },
  ]
}

luke(\\.| )?foreman expands to:

1. Luke.Foreman - email addresses
2. Luke Foreman - Full name
3. LukeForeman - Ticketing user names

(\\bLuke) means Luke where it starts on a word boundary. This is to try and prevent false replacements like where the name to replace is Ash and the text contains dashboard.

(\\bLF\\b) match exactly LF and it must have a word boundary on either side, commonly in the text we use initials when referring to

Software Specification

Write a Software Requirement Document (With Template) [2024] • Asana