Design of

Biomedical
Devices
Module 2-Class-6 Design Phase
SOFTWARE DESIGN
Many medical devices are rapidly becoming software intensive. Software controls their operation, collects
and analyzes information to help make treatment decisions and provides a way for users to interface with the medical
device. In these devices, the software transforms a general-purpose computer into a special-purpose medical device
component. As in hardware design, specifying the software requirements, creating a sound software design and
correctly implementing it are difficult intellectual challenges. Software has additional challenges. It is nearly
impossible to measure software to determine if it meets the first test of quality: that it exists as specified. And
software provides a great deal of flexibility to work around hardware or other problems, particularly those discovered
late in development. We can only address these challenges with a disciplined, methodical approach to the creation of
software, i.e., software engineering.
It must be noted that the term software design has multiple meanings. Design used in the context of the medcal
device encompasses all the activities that occur before manufacturing of the device begins. Since software is entirely
abstract, all of the software development activities occur before the manufacturing phase begins .So all of the
activities done for software development are part of the device's software design. There are also specific technical
activities that are performed during the software development that are called software design. These activities
translate what the software must do into how these requirements will be accomplished by the software. They also
organize the software to take into account the use of the details of the physical features of the medical device in
accomplishing the device's purpose.
Fundamentals of Software Engineering Management
• Planning.
• Estimation
• Tracking progress
Planning Software Development
Planning encompasses more than just documenting resources needed for the project and creating a schedule. It includes
looking at the project from a management view including schedule and resources, as well as looking at how the work
will be done.
• What development model should be used?
• What methodology?
• What programming language and tools?
• Identifying how the software will be controlled, and how it will be tested.

A key input to planning for medical device software is safety risk. The most important factor is the greatest severity of
injury that can result from a software failure.
These are the objectives for the project and the assumptions made.
Another area that good planning addresses is relationships between groups.

Subcontractors are often used for developing parts of the software. This can be a very useful approach, reducing
development time and adding expertise in an area where the development team may not have much
experience.
Project risks are another topic that planning should address.Establishing the four CS for all significant foreseeable risks
will provide a great deal of help should one or more of them become a problem: chronology (when
will the risk be quantified), contingencies (what are the possible courses of action that could be followed),
consequences (what are the likely results of each action), and criteria (how will the course of action be chosen)
1.Choosing the Software Development Process Model

For any software development, there are some fundamental activities that always are performed, and some optional
activities that are included to improve the likelihood of meeting specific project objectives such as short development
schedule, high reliability, or high conformance with customer desires. The sequence in which these activities are performed,
and the formality with which they are performed and documented may vary. A software development process describes the
activities to be performed and defines the chronological ordering of these activities. In order to define the development
schedule, a software development process model must be selected. There area number of basically different software
development process models, with many variations. Whether a particular model is appropriate depends on the goals of the
project and the level of concern of the software.

Development Process Models for High Level of Concern.

If the requirements of the software are established and reliability is a major objective, such as for software with a higher
level of concern, these software development process models should be considered.
The main software models are:
1. Waterfall Model
2. Incremental Delivery Model
3. Spiral Model
4. Cleanroom Model
Waterfall Model
This was the first documented software life cycle model. It divides the development process into steps, each of
which reduces the level of abstraction of the solution. Each step includes a verification task and an exit criteria
that must be met before moving on to the next step. As much as possible, iterations of a step are performed
during the subsequent step.
The waterfall model's advantage are that it helps find errors early and provides a well understood structure. Its
difficulties are that the requirements must be fully specified at the beginning of the project, before any design
work has started. Finding out that requirements are wrong or incomplete late in the project can lead to extensive
rework. The waterfall model works best for complex systems where the requirements and technical
methodologies are well understood.
Incremental Delivery Model
The incremental delivery model is a modification of the waterfall model. It starts like the waterfall by analyzing
requirements and creating an architectural design. Instead of delivering all of the software functionality at the
end of the project, the functionality is divided upon to increments that are delivered successively through out the
project. Each increment refines the requirements and architectural design, then does detailed design,
implementation, verification and release of its functionality.
This model works well when there is a need to deliver partial functionality before all of the functionality is
needed. For example, a new medical device might need some software functionality for early hardware testing,
additional functionality for validating expected clinical results in animals, more functionality when a human
clinical study is performed, and the complete functionality for the market release of the device.
Spiral Model
• The spiral model was developed by Boehm to address some of the difficulties with the waterfall model. The
spiral model iterates a set of steps, creating in effect a series of mini projects. Each of these mini projects
completes a loop around the spiral. The first step in each of these mini projects is to determine the objectives,
alternatives and constraints for the portion of the product being developed. The next step is to determine risks
and resolve them. Then the alternatives are evaluated, the deliverables for the iteration are developed and
verified and a plan for the next iteration is created
• The main advantages of the spiral model are its flexibility and that it is risk driven, and as the project
progresses and costs increase, the risks decrease. The disadvantage is that the spiral model requires expertise
in risk management.
Cleanroom Model
• The cleanroom model was created to develop software that has a predictable
reliability. It combines a set of techniques that depend on verifying the correctness of
each step in the development process model. This results in more formality in
specifying requirements, performing design and implementing the design in code.
Since each step is verified as correct, cleanroom eliminates structural testing. It uses
a statistical approach to functional testing to demonstrate that the requirements
were implemented and to measure the software reliability in terms of mean time to
failure(MTTF).
• The design must proceed in small steps, each being verified to be equivalent with its
predecessor. Verification based inspections, which inspect for correctness rather than
defects, are used to provide independent confirmation of the design’s correctness.
Software coding proceeds in a similar manner of stepwise implementation and
verification using inspections. Since the code is verified for correctness to the design
no developer debugging or unit testing is needed.
The Cleanroom
Process
Development Process Models for Low Level of Concern Software.
1.Design to Schedule Model.
2. Evolutionary Delivery Model.
3. Code and Fix Mode.
1.Design to Schedule Model.
This model prioritizes functionality and then develops it incrementally, with the early increments having the highest
priority features. The difference between this model and the incremental delivery model is that with the design to
schedule model you quit when the deadline is reached no matter how much has been delivered. At the beginning of the
project, it is unclear how many of the planned increments will be completed.
2.Evolutionary Delivery Model.
This model is used when requirements are changing rapidly or are not understood very well at the beginning of the
project. The portions of the system that are best understood are developed and delivered. Feedback is gathered from
users or potential users and the additional understanding is used to evolve the product to another version, which is
developed and delivered.
This iterative process is repeated until the users are satisfied
that the necessary functionality is present in the software.
Code and Fix Mode.
If no planning is done, the default that gets used is called the code and fix model. It is not really a software
development process model, but more the lack of one. With the code and fix model, you start with an idea of
what you want to build, maybe write some specifications, then start coding, debugging and testing. As problems
are found they are fixed and sent back for more testing. When the number of problems being found in test falls
to an acceptable level, or you run out of time to do more testing and fixing, you release the product. This model
is not recommended for any type of software development and is clearly not acceptable for any development in
which software could result in loss of safety.
2.Choosing a Design Method
As with development process models, there are number of basically different software design methods with
many variations. They each provide criteria for expressing and refining the principles of good software design.
Most software design methods take ono of three approaches:
• Top-down structured analysis and design
• Data-driven analysis and design
• Object-oriented analysis and design.
All these methods use decomposition to divide a complex problem into parts that are small enough to be
understood and implemented correctly
1.Top-down structured analysis and design.
• It is a top- down refinement approach that presents details in a layered fashion, hiding the detailed
information regarding the design until the appropriate level. Structured analysis shows how data logically
moves through a system being transformed by processes. Each process is decomposed into another set of
processes and data flows providing more detail. The logical building blocks are algorithms, and the system is
decomposed until the function of each process is a simple algorithm performing a single function. Structured
design partitions the system physically into modules that are organized into hierarchies with defined
interfaces. Each module should solve one piece of the problem. Each module should be easy to understand.
Connections between the modules should be as simple as possible. Each module has four attributes: input
and output, function, internal logic and internal data.
• Data-driven Analysis and Design.
• Data-driven analysis and design derives the structure of the software from the structure of the data that is
input to the software and the structure of the data that is output by the software. These input and output
structures are first modeled using a graphical notation. They then are converted into a program structure that
maps inputs to outputs. The processing necessary to make the transformation from the input to output can be
identified and associated with the program structure. The processing can then be decomposed, as necessary.
Data-driven design has been applied primarily to systems where input and output structures can be well
defined and which have little concern for time-critical events, such as information management systems.
• Object-oriented Analysis and Design.
• Object-oriented analysis and design groups data and the functions performed on that data into a
single entity called an object. Rather than identifying data structures and process structures
separately and then decomposing each, the object-oriented approach models systems in the real
world as collections of objects which collaborate to perform some behavior. Objects can be
identified; they can take action and the current values of their properties can be determined. These
characteristics are called identity, behavior and state. Objects communicate by messages which
cause the receiving object to take an action.
3.Choosing a Programming Language
Programming languages are the tools used to transform the software design into executable instructions
for the computer. The manner in which the programming language chooses to implement fundamental
design concepts impacts the usability of the language. The trade-offs between programming languages are
on characteristics such as ease of use, flexibility, performance,size of code generated ,ease of maintenance
and availability of development tools. The choice of programming language depends on the type of
problem,the availability of tools for the target hardware, the design method chosen and the objectives of
the project.
4.Estimating and Scheduling
Once the choices of development process, design method and programming language have been made, it
is possible to estimate the size of the software and the effort required for developing it. Of course, the
more that is understood about the requirements, the more precise the estimates can be. Often, estimates
must be made very early in the project, long before the details are known. There are several techniques
and heuristics that can be used to help produce early estimates for planning the project. One technique that
is valuable is to use more than one method to estimate. This may include estimating the effort for each
module based on past experience with similar modules, design and programming language. These
estimates can be summed to provide an overall estimate for the project. A Second method would be to
estimate the size of the modules using lines of codes or function points and then using one of the
parametric tools available, such as COCOMO or SLIM. These tools will provide estimated effort for the
project based on size and other parameters. If the estimates from different methods differ widely, more
work must be done to understand why, and which estimate needs modification.
5.Tracking Progress
Once the estimate is complete and a schedule in place, tracking progress to the schedule is necessary to control the
project. The most common way of tracking and communicating progress is called earned value accounting. It integrates
scope, cost, and schedule measures to assess performance. Earned value involves calculating three key values for each
activity
• The planned cost of the activity. This is called the budgeted cost of work scheduled (BCWS)
• The actual cost of the activity. This is called the actual cost of work performed (ACWP)
• The earned value, also called the budgeted cost of work performed (BCWP).This is a percentage of the total budget
equal to the percentage of the work actually completed
These values can be used to calculate the cost variance (CV = BCWP - ACWP) and the schedule variance(S V = BCWP -
ACWP) at the time of the progress report. They can also be used to forecast the project cost at completion and the
project completion date.
6.Software Requirements Analysis and Software Requirement Specification(SRS).
This is the first technical step in the software engineering development process. Software requirements analysis
refines the system requirements allocated to software to provide a model of the software behavior. The first task
in software requirements analysis is to fully understand the basic elements of the problem that the software must
solve. This includes identifying the exact purpose of the system, who will use it, and what the constraints are on
the possible solutions. Once the problem is completely recognized, the functionality and data necessary for a
solution are identified. Various alternative solutions can be analyzed and evaluated based on the criteria most
important for the particular application. The results of this analysis is a set of function, data, performance and
external interface requirements that define precisely what to build. These requirements make up the software
requirements specification. The SRS plays many roles in a large development project.

1..It is the contract between management and the development team on exactly what is to be built.
2. It records the results of the analysis. It shows where the requirements are complete and where additional work
is needed.
3.It defines what properties the software must have, and where there are constraints that limit the design
choices.
4.It is used for estimating size and determining cost and schedule.
5.It is used by testers to determine acceptable behavior of the software.
6.It provides the standard definition of the expected behavior of the software for the system's maintainers.
If any commercially available off-the-shelf software is being included in the medical device software, it must
be fully identified in the software
7.Software Hazard Analysis.
For medical device software, software requirements analysis must also specify safety requirements. Identified
system hazards that have been traced down to software must be mitigated by requirements or constraints on the
software's behavior. These requirements and constraints are also documented in the software requirements
specification and must be consistent with the rest of the software requirements.
The most direct way to trace system hazards to software is with a top-down fault tree analysis. How the software can
contribute to the hazard condition is determined, and then requirements or constraints are identified that will prevent
this software condition from occurring. When the software condition can be prevented by adding functionality, a
requirement is written. If the software condition can only be prevented by constraining something from happening, a
design constraint is written. Requirements are much easier to implement and verify than constraints and should be
used to mitigate the software condition if possible. After these safety requirements and constraints are documented,
it must be shown that the software requirement specification satisfies them. To do this, the software requirements
specification must completely describe the behavior of the software under all conditions. Checking the software
requirements specification for completeness requires analysis of states, transitions between states, inputs and
outputs, values and timing. Some examples of criteria for checking specification completeness are :
• Every software state must be reachable from the initial software state
• Every software state must have a behavior specified for every possible input
• All information from sensors should be used somewhere in the specification
• Interlock failures should result in the halting of hazardous functions
• All incoming values should be checked and a response specified in the event of an out-of-range or unexpected
value
• The response to excessive inputs must be specified
• Safety-critical outputs should be checked for reasonableness and for hazardous values.
8.Requirements Traceability
To assure that all requirements are implemented in the product, each requirement should be traced to the component of the
design where it is implemented. In order to accomplish this, each requirement and each design component must be uniquely
identified.
• Traceability information can be maintained in traceability tables or in traceability lists. A traceability table is a matrix
with requirements on one axis and design components on the other. The cell that is at the intersection of the requirement
and the associated design component contains an entry showing the relationship. In a traceability list, each requirement is
identified, along with a list of the design components that implement it.
• To assure that all hazard mitigations result in requirements that are included in the software requirements specification,
the hazard mitigations should be traced to the software requirements specification in the same manner that the
requirements are traced to design components.
9.Software Architectural Design
• It partitions the real-world problem (the software requirements) into elements of a software solution and organizes the
relationships between these elements. The primary objective is to achieve an abstract representation of the structure, both
of control and data. If the behavior of an element can impact other elements, that behavior should be described in the
architecture. A modular program structure defining the control relationships between components and an organization of
the logical relationship among the data elements is the starting point for software design. Some rules of thumb for good
architectures ;
• Well defined modules with functionality based on the principles of information hiding and separation of concerns.
• Hardware specifics should be encapsulated
• Dependencies on commercial tools or products should be encapsulated.
• Separate modules that are producers of data from those that are consumers of data.
Software Architectural Design
10.Detailed Design
• Detailed design refines the abstract architectural design,filling in the details necessary to construct the final
product. Detailed design must specify algorithms, data representations, connections between different
processing elements and between processing elements and data structures. Detailed design must also be
concerned with the packaging of the software product. Detailed design is performed using the chosen
methodology. No matter what design methods and techniques are used, there are a number of fundamental
design concepts that are important.
• Modularity - The design should identify components or modules, and each module should solve one well-
defined piece of the problem. The purpose of each module should be well defined. Each module should
include the functional processing, data structures and control mechanisms necessary to achieve its purpose.
Modules should communicate with each other using well-defined interfaces
• Information hiding- The internal processing details and data used by a module should not be observable
from outside the module. The design decisions and their implementation should be hidden from other
modules. This allows the detailed design and implementation decisions to be changed without impacting
other modules.
• Structure - This determines how the processing in a module is organized and controlled. If the software is
thought of as a network, made up of processing nodes connected by control or data links, the logical path
through the network is the structure. Examples of structure include hierarchical ordering and concurrent
ordering. In hierarchically ordered modules, the processing elements are related by "uses" and "is used by"
relationships. In a hierarchy, process nodes execute sequentially ,the relationships are directed, and a node is
not allowed to use a node that precedes it in the sequence. In a concurrent structure, process nodes execute in
parallel and control is maintained by use of shared variables and message passing, using mechanisms such as
semaphores and queues.
• Encapsulation - If a data structure can only be accessed by routines packaged with it in a single module it is said
to be encapsulated. Other routines that use the data structure do so by using the access routines. They do not need
to know how the data structure is implemented.
• Cohesion - This measures the strength of the relatedness of elements within a module. Maximizing cohesion will
reduce the number of interconnections between modules. Cohesion is described as (from weakest or least desirable
to strongest or most desirable):
• Coincidental cohesion - elements within the module have no apparent relationship to one another
• Logical cohesion- elements within the module perform similar functions
• Temporal cohesion - all elements are executed at the same time
• Communication cohesion - all elements refer to the same set of input/output data
• Sequential cohesion- the output of one element is used as the input for the next element
• Functional cohesion - all elements are related to the performance of a single function
• Informational cohesion - each element performs a single function, and all elements refer to a single data structure.
• Coupling - This is the measure of the strength of connections between modules. It measures how well information
hiding has been achieved.
• The stronger the coupling between two modules, the more likely that change in one of the modules will
require a change in the other. Coupling is ranked from strongest (least desirable) to weakest (most desirable)
• Content coupling - the module modifies internal data or instructions in the other module
• Common coupling - all modules share global data items
• Control coupling - a module passes control flags that determine the sequence of processing in another module
• Stamp coupling - only modules that require the data share global data
• Data coupling - data items are passed between modules via parameters.
11.Implementation (Coding)
• After a module has been designed the design must be translated into source code. This is a detailed, labor-intensive task.
The primary goals are to write the code so that its purpose is clear, so that it correctly implements the design, and so that it
will integrate easily into the system. Simplicity and clarity are desirable characteristics, complexity and cleverness are to be
avoided. This is especially true in any software that is critical to safety. In this case, standard techniques should be used that
are easy to understand and are easily documented.
• To consistently achieve the desirable code characteristics, coding standards are used to specify a preferred coding style.
Coding standards usually include items such as:
• 1. Naming conventions for variables and functions
• 2. Guidelines for scope of data
• 3. Guidelines for using specific types of data
• 4. Guidelines for control structures
• 5. Use of assertions and other error detection practices
• 6. Specific items to be aware of in the particular programming language
• Documentation that is included with the source code should provide the information necessary to maintain the module. This
documentation should address how the module accomplishes its function and illuminate any portion of the code that may
not be sufficiently self-documenting. The documentation generally consists of a prologue or header which has a standard
format and comments embedded in the code that explain major data manipulations or end cases and exception handling.
12.Integration
• Integration is the combining of code that has been implemented independently into a single system where it
must work together. One approach to integration is to have a specific integration phase in the development
process model. The individual software modules are built in the previous phases and then combined into a
system in the integration phase. This is often referred to as "big bang" integration. While it is possible to wait
until all the code has been developed to put it together as a system, the effort required to get everything
working may be very great. In practice it is much more efficient to integrate the code a small piece at a time.
This approach is called incremental integration, or sometimes continuous integration. Incremental integration
requires establishing an initial system and then adding just a little additional code at a time, while making
sure that the system continues to operate. This requires careful planning and tight control over the order in
which code is added to the system since modules must be integrated after other modules which they depend
upon. The integration control process must include criteria for including new code in each version of the
system.
• Incremental integration has several additional advantages. Each software element can be tested as part of the
system, eliminating then need to develop a special testing bed to test the new software element. Incremental
integration also provides a focus on the source of problems. If a problem appears, it is probably related to the
new module being added to the system, either in the new module itself or in the interfaces between it and the
rest of the system. Incremental integration also provides flexibility, since it is possible easily revert to the
previous system if adding a new module results in a problem
13.Software Configuration Management
• The goal of software configuration management is to control and track changes in the software to assure that nothing is
lost or destroyed. Change will occur during all phases of the software development process. The reason change occurs is
that the more is known about the customers needs the device requirements, the software design, etc. These changes are
necessary and valuable but can lead to a great deal of confusion and rework if they are not coordinated and controlled.
• Conclusion
• Software is becoming a key technology in medical devices. To produce safe, reliable software requires a methodical
engineering approach The management activities of software engineering; planning, estimating, scheduling and tracking
progress, are required before the technical software engineering activities can be successful.
• Key decisions to be made during the planning include what software development process model to use, what design method
will be followed and what programming language will be used to implement the software. After deciding how the software will
be developed, estimates must be made for effort and schedule. At least two different methods of estimating should be used, and
the results compared. After establishing the overall estimates, a detailed plan is necessary which breaks the project down into
small pieces of work that can be assigned and measured. Overall project progress should be tracked to control the project. The
most common method of tracking project progress is the earned value accounting method
• The technical activities in developing software that are always necessary, regardless of the development process model are:
1. Software requirements analysis
2. Software hazard analysis
3. Software architectural design
4. Software detailed design
5. Software implementation
6. Software integration
7. Software configuration management,
Executing the basic tasks of these activities using defined methods and established criteria is the best way to create reliable, safe
Questions:
1.List out and explain the fundamentals of software engineering management.

2.List out the high level of concern software development process models and explain briefly each model.

3. List out the low level of concern software development process models and explain briefly each model.

4.List our three approaches in the software design method and briefly explain them.

5.Explain any one of software design methods applied to the development of software of your project or any
product.

6.What are all the factors to be considered when choosing a programming language of software design.

7.Expalin the how the software development design process is tracked with reference to the various cost
variances.

8.Briefly explain software requirement analysis and software requirement specifications.

9. How is hazard analysis carried out during software development?

10.Explain detailed design methodology of software development.

11.What are all the factors to be considered during the implementation phase(coding) of software
development.