Address Dr. Wassyng feedback

[JovieL25]

Keep track of the feedback from Dr. Wassyng that I will be addressing for my MENG report.

• [x] Introduction, section 1.1.3 change "AC can be thought of as" to "is"
• [x] Introduction, section 1.2, changed the following sentence to "By constructing the AC, we were able to follow a systematic and structured approach of software development". The original comment is attached below.
• [x] #68
• [x] #69 The full sentence is: GR, GI, GA and GBA, where GR stands for the goal of correct requirements of the software, GI stands for the goal of the implementation matching the requirements, GBA is the goal of that all operational assumptions have been defined, and GA is the goal that all operational assumptions are met. While a hazard analysis is typically included in an assurance case for medical applications, we chose to concentrate solely on an assurance case concerning the accuracy of the calculations to save time.
• [x] #71
• [x] Chapter 3, Figure 3.2, comments attached below.
• [x] #70
• [x] #72

[JovieL25]

Hello Dr. @smiths,

I am unsure how to address this comment from Dr. Wassyng, the statement is attached below.

My comment would be that AC will not affect the development, but one key evidence of GI is that a reviewer understands the implementation and agrees on the methodologies.

[JovieL25]

Things to consider adding for GBA:

1. The operational assumptions are defined as precisely as possible.
2. The operational assumptions coverage.

[smiths]

Hello Dr. @smiths,

I am unsure how to address this comment from Dr. Wassyng, the statement is attached below.

My comment would be that AC will not affect the development, but one key evidence of GI is that a reviewer understands the implementation and agrees on the methodologies.

@JovieL25 for future questions to me, please create a separate issue per question. It is challenging to keep track of multiple threads at once.

What Dr. Wassyng has noticed is true. We did the development and then we did the AC. I thought we could "fake it", but in retrospect Dr. Wassyng has a good point. The recommended approach for developing software is to work on the AC concurrently with developing the software. You can address this comment by stating at the beginning of the report that your process was to develop the software and then document the AC. At the end of the report you can say a future recommendation that the assurance case should be developed concurrently with the other development tasks.

[smiths]

@JovieL25 did I answer all of your questions?

[JovieL25]

Hello Dr. @smiths, I am unsure how to address this comment from Dr. Wassyng, the statement is attached below. My comment would be that AC will not affect the development, but one key evidence of GI is that a reviewer understands the implementation and agrees on the methodologies.

@JovieL25 for future questions to me, please create a separate issue per question. It is challenging to keep track of multiple threads at once.

What Dr. Wassyng has noticed is true. We did the development and then we did the AC. I thought we could "fake it", but in retrospect Dr. Wassyng has a good point. The recommended approach for developing software is to work on the AC concurrently with developing the software. You can address this comment by stating at the beginning of the report that your process was to develop the software and then document the AC. At the end of the report you can say a future recommendation that the assurance case should be developed concurrently with the other development tasks.

Ok, I will make separate issues!

[JovieL25]

This issue closed as PR https://github.com/smiths/aorta/pull/73, addressing the feedback of Dr. Wassyng is merged with the main branch.