In this segment we'll present a template for the software design document has similar template and what we had for the systems requirement. Specification is meant to illustrate the concepts for this introductory class and cover the main topics that one would encounter in this type of design. So what does the outline look like for this introductory class? Or again have a cover patient revision control page. The same ideas in the system requirements. All documents in this process have to have a covered patient vision control page. What are the overview, the summary of the system, what are the inputs and the outputs. Where does it fit in the overall pipeline of our users needs. A big picture design and this has three components at least in my way of doing this, we'll have a workflow description. We'll have the module architecture and we'll have an outline schedule of the user interface. And then we have the specification of the workflows item by item the steps and I like to break that down into the what, how to test and what could go wrong here. And we'll come back to this and just show an example late. And then finally, we'll talk about the external dependencies. So for each library, we'll list its description, the author of the license, the version number and any secretary dependencies this introduces. The last step and we're just going to show very carefully outline for this is things like packaging globally and distribution. You need to be mindful of these as you design software, we will not spend a lot of time on this last section. That's more domain specific. The cover and revision control page look identical to what we have for the system requirement specification. Again, the control page lists the changes done in this document so we can see how it was changed and when. And the title page includes a signature and the date here, 11/2019 and somebody signs it. This is for the design history file. So we have the evidence that we've had a plan and that we follow that plan and this is part of that process. This is the design controls guidance. So let's start at the beginning, we have the overview, the summary of the system, we describe where our software fits in the user's workflow. We specify it's interactions with the rest of the world. From what are the inputs? Where do they come from? What are the outputs? Where do they need to be stored? And we describe things like file formats, database/network protocols and all the things that specify the outside box effectively in which our software fits. The next step now is to think about the big picture design and we'll break that into three steps. The workflows. These are flow charts, the module architecture and then an outline schedule the user interface. So let's start with the workflows. The workflows, think of them as the design that faces towards the user from the user's point of view. We create workflows to satisfy all the requirements and we create flowcharts to describe these. So let's take a simple workflow. This is to smooth an image that's humor softer wanted to do some smoothing of an image. A rail flaw has five steps without the image. We set the amount of smoothing with smooth the image. We review the smoothing and we actually save the image. So this is a workflow to meet one particular requirement. So the goal here is to capture the requirements into workflows who can constrain the user to reduce the possibility of error to give them a streamlined process, ABCDE, when the user is stressed, when they have a small amount of time, when they're using a software for the first time after three weeks, they shouldn't have to think very hard. There should be a streamlined process. So this is the view from the perspective of the users, they have the five things they have to do to successfully complete the user need as described by that requirement. The next step is the architecture of our software. We have the overall system and its major subsystem. So typically, if this big circle is a software, these yellow things are the major subsystems and we ensure the communication links between the subsystems and the communication links between the system and the rest of the world. So the printer connects with subsystem C, see the user input goes to subsystem A, the database connects with subsystem B, and this information from A to B and A to C and from B to C but not otherwise. This tells you how information flows into the system. So this is a high level software description. And then the last part is the user interface and it could be a schedule of the interface, all the core views the main things in there and this provides some vision for the personal implementing this, what are we expecting this user interface to look like? Now, there are tools for doing this for example, something called Figma, my students love to use and we'll talk a lot more about user interface design in the context of usability in segment four of this week's class. So once we have the big picture design, we need to specify the workflows item by item and this is our smoothing workflow on the top left corner here. And we're going to just pick up the second item here to set the amount of smoothing just to illustrate how that gets specified. So we have a background section. The amount of smoothing is the standard deviation of the Gaussian filter that will be used. The default value is 2.0, and there's more of a description here. Procedure, you probably dialog to select smoothing in allowed range 0.5 to 10 ,if the user presses OK, then we proceed to the next workflow smooth, if the user presses Cancel, we'll close that dialog and go back to the start. To test, if OK is pressed the smoothing happen. If Cancel is pressed, does it stop? Does the smoothing value stay in the allowed range? And what could go wrong, if the image is too large, the process could take a significant amount of time and/or result in a system crash. So this is the specification of once they've been a workflow, the background, why we're doing what we're doing, the actual procedure, how would one test it and some building risk management? What could go wrong, so we can now think about capturing some of this in the actual design. The next step is this external dependencies and we're going to spend a couple of slides on this because it's a very important topic. We need to describe the external libraries and the tools that will be used to implement, compile and test the software. The compiler is part of our external dependencies. The libraries are part of those. And here we have a challenge. We want to minimize the dependency of the software on external libraries, the SOUPs. This is code for which we have no control over and which may introduce additional risks that we need to manage. So we really would like to, as much as possible, have the smallest number of dependencies. On the other hand, we should not constantly reinvent the wheel and the goal and the trade off is to use well known, widely used, well tested libraries that have a reputation for quality, that have been used by other important projects. They may lack a QMS, especially if they're open source documents, but they may have some of the quality attributes for example, code reviews and detailed testing. And this is a critical component of this process, figuring out what to reuse versus what we have to develop in house and that balance determines a lot about our software and figuring out what the set of external libraries that we can reliably depend on. And we only use that small, tightly chosen sort of dependencies as an important part of the design process. So to discuss this further, we have a short video clip for Dr. Steve Pieper from ISIS Comics and Brigham and Women's Harvard Medical School to talk explicitly about this concept of selecting dependencies. >> So one of the things that I found, probably indispensable is collecting a curated set of dependencies that you can have some confidence in, that you're willing to commit your career effort, your mental investment to learn to do well and to understand and also to keep up with and often participate in the communities that are maintaining those. For medical devices too, these can be relationships with your commercial in nature. There are people who will sell you a very high level dependencies and you can think of them as software packages but they're really not that much. But the open source license that says, hey, you can use this for anything you want, but you're responsible for figuring it out on your own. That still costs you money. Because you have to understand the maintenance, you have to convince yourself that is working right. Somebody else may say, here's my essentially ready to use solution that will perform the specifications, X, Y and Z. You have to pay for that, but then maybe you're correct in assuming that it really will perform to those levels or maybe you're sense of testing this, relax a little bit in that because you're focusing on something else. So either way, you're making an investment and choosing a dependency that will help you achieve what you want to achieve. >> And a critical component of this is that the dependencies that you trust, the libraries you are able to use, that you used in previous projects perhaps, may constrain your software design because this is the only library we use for this task. This library have some limitations which may constrain your design and now you have to make a decision as to how you proceed. A related issue, when we think about external libraries is open source code, and again, we select reputable library with a large user base, we look for testing, we look for documentation. You download the version of the open source repository and you freeze it and you do all the testing on this frozen version and then finally you need to check the licensing for compatibility commercial applications. There are two basic styles of library licenses, there's GPL style viral licenses. So here when you use any GPL code, it makes your code open source under the GPL. And then they're BSD-style licenses where you simply acknowledge the use of the code without further constraints. Typically for commercial products, you want to stay on the BSD side and avoid any kind of GPL license software. They're small exceptions to this rule, but that's a good general piece of advice. So to give us a description of this a little bit more, we have another clip here from Dr. Andinet Enquobahrie from Kitware, Kitware is a major open source library company and that's what they do. And he'll tell us a little bit more about the use of open source in medical devices. >> As part of your product development, and I think this is very important, you have to take a particular version of what's already available on the open source community and lock down that version and then do your lot of internal testing. Because obviously it's open source, it's going to continue to be changed, it's going to continue to be modified and that's not going to stop. But, in fact this is one of the requirements from FDA anyways, which is, it's okay, you can use open social library, but they want you to lock down a particular version of VTK and ITK and then put together a testing infrastructure around it and then rigorously test that particular version internally. And that's going to be part of your product development. >> So unlike what you may have heard, open source is fine. You may use open source libraries is just that you have to manage the process appropriately. And part of it is ensuring that the version that you select does what it's supposed to do and you do the appropriate testing, et cetera. So the final step is this concept of packaging, labelling, distribution. So, the software should be distributed with an appropriate set of labels that describe the origin, the corporate holder, the compliance level, what the software is approved for, and any other information that is necessary for its use. So to give an example, this comes from the UK guidelines and this is what they expect to see for mobile labs that get sold on upstores. This is the type of label in the C. So the month and the year. The company, the app is intended for, warnings intended for, and this is the UK mark of compliance here, the UK CA mark. That's equivalent to C mark for the United Kingdom right now. And then we come back to risk management. So we always have to review everything from the perspective of risk. So we review the overall structure of the design for risks. Is the user interface confusing? We'll talk about that when it comes to usability. Could it lead to misuse? What failure at any part of the workflows create a hazardous situation for the patients or users? So this is things we have to think about. And we also have to think about cybersecurity in this day and age. Any time we have any piece of software, especially that connects to the Internet, relies on a server, connects to a server, is the server that becomes critical. The second part of the risk management process, is we have to think about the design from perspective what could go wrong and we talked a little bit about in the risk management sections in week four, but let's review this. Certain components are likely to be high risk due to history of issues. We have complexity risk, perhaps buggy code, perhaps what we're trying to design is not feasible given our resources, perhaps something will be too costly to implement. That is a risk management step. We need to do a risk analysis of the software and the risk analysis may result in upstream changes to the systems requirement specification. Perhaps the design is over optimistic and when the software engineers get their hands on it to design software, I think we can't do it. So the appropriate thing to do is to stop and move back to redesigning the system. So, we came from the system requirement, we moved down to software design. If there's a problem with the requirements, that means that the design is not going to be good. We go back and we force the system requirements design before we go into the software design. So this concludes the discussion of the software design template. In the next segment, we'll get more concrete and we'll look at what this looks like for our image guarded neurosurgery project. Thank you.
