taranjit-samra-march13

PDF

Download

Open document

Flip pages

Summarize

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content
SOFTWARE RISK MANAGEMENT: AN EXPLORATION OF SOFTWARE LIFE
CYCLE METHODOLOGIES, BEST PRACTICES AND TOOLS FOR THEIR
APPLICATION TO MEDICAL DEVICE SOFTWARE RISK MANAGEMENT

by

Taranjit Singh Samra

________________________________________________________________

A Dissertation Presented to the
FACULTY OF THE USC SCHOOL OF PHARMACY
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
DOCTOR OF REGULATORY SCIENCE

May 2012

Copyright 2012 Taranjit Singh Samra

ii
DEDICATION
I would like to dedicate this dissertation to my family, my wife Shaminder
who wholeheartedly supported me to pursue this doctoral program, and endured its
grueling schedule during the last few years; my daughter Mehtab and son Zorawar,
who put a smile on my face every single day, and inspire me to be their role-model;
and my father Gurnam S. Samra and mother Baldev K. Samra, who motivated me
since my childhood to strive for the highest in education.

iii
ACKNOWLEDGEMENTS
It is my pleasure to thank everyone who supported me throughout the
doctoral program and made this thesis possible. First and foremost, I would like to
express my sincere gratitude to my thesis supervisor, Dr. Frances Richmond Ph.D,
for her guidance, continuous mentoring and encouragement throughout the program.
Her logical way of thinking, especially through the thesis writing process, has been
invaluable. I would also like to thank Dr. Gerald Loeb M.D, for the key feedback
and review of major milestones throughout the thesis to keep me on the track, and to
my other thesis committee members, Dr. Hilton Kaplan M.D, Ph.D, and Dr. Daryl
Davies Ph.D for goal refinement and helping define the overall objective of my
doctoral research. In addition I would like to acknowledge the help from Dr. Kathy
Rolle EdD and Kimberly Horwood MS through various administrative hurdles
during the entire program, and Dr. Michael Jamieson DRSc in thesis formatting and
clarification of graduation requirements. Finally, I would like to thank other students
in the 2008 DRSc Cohort and the staff of the USC Regulatory Science program for
their support over the last three and a half years, both at the personal and
professional level.

iv
TABLE OF CONTENTS
Dedication ii
Acknowledgements iii
List of Tables vii
List of Figures viii
Abstract xi
Chapter 1: Introduction 1
Background of the Problem 1
Statement of the Problem 4
Purpose of the Study 5
Significance of the Study 6
Delimitations, Limitations and Assumptions of the Study 7
Definition of Terms 9
Chapter 2: Literature Review 12
Formalized Risk Management: a Short History 13
Software Risk Management (SRM) 18
Risk Management Practices Through the Product Life Cycle 24
FDA Guidance and International Standards 24
Other Literature 32
Software Development Methodologies/Processes 51
FDA Guidance and International Standards 51
Choosing a Process Methodology 57
Software Development and Lifecycle Management Tools 66
Conclusion of Literature Review 71
Chapter 3: Research Methodology 74
Stage 1: Initial Exploration of Methodologies and Tools 74
Stage 2: Evaluation of Software Development Trends for 76
Medical Devices
Data Analysis and Development of Integrated SRM Framework 78
Chapter 4: Results 80
Software Development “Methodology/Process” 80
Software Development Methodologies/Processes: 81
Traditional vs. Agile
Applications of Agile Method in Medical Device Industry 84

v
Experience of Agile Methodology Among Medical Device 87
Companies
Regulatory Views on the Use of Agile Method in Medical 95
Device Industry
Risk Management Best “Practices” 97
IEC 62304:2006 Risk–based Software Development 98
Human Factors Engineering (HFE) 101
Use of Assurance Cases 103
FMEA/FTA 106
Use of V&V Activities 108
Post-development Risk Management Activities 111
Software Development and Lifecycle Management “Tools” 111
SDLC and ALM Tools 113
Use of ALM and SDLC Tools Among Medical Device 123
Companies
FDA’s View on the Use of SDLC Tools in Medical Device 128
Industry
Inventory of Tools 129
Chapter 5: Discussion 131
Consideration of Methods 131
Consideration of Results 136
Agile as a Software Development “Methodology/Process” 136
Building an Integrated Risk Management System on Agile 141
Methodology
SRM Automation Using SDLC and ALM “Tools” 149
Automated Software Risk Management (SRM) Framework 154
SRM in Other High-risk and Regulated Industries 157
Conclusions and Future Considerations 160
References 163
Appendices 176
Appendix A: List of Seminars From Which Study Data was Collected 176
or Interviews Conducted
Appendix B-1: Interview Questionnaire: Software Development 177
Methodology/Process and Risk Management Practices
Appendix B-2: Interview Questionnaire: Software Development and 178
Lifecycle Management Tools
Appendix C-1: Details of Study Participants and Data Collection: 180
Software Development Methodology/Process

vi
Appendix C-2: Details of Study Participants and Data Collection: 184
Risk Management Practices
Appendix C-3: Details of Study Participants and Data Collection: 187
SDLC and ALM Tools

vii
LIST OF TABLES
Table 1: Steps of Research 73
Table 2: Participants and Data Sources of the Study 77
Table 3: Comparison of IEC 62304 and FDA Guidance 99
Table 4: Requirements Management Tool Evaluation (Seilevel, 2011) 115
Table 5: Requirements Management Tool Evaluation (Krasner, 2010; 116
High Rely, Inc.)
Table 6: SCM Tool Evaluation (Krasner, 2010; High Rely, Inc.) 118
Table 7: Code Analysis Tool Evaluation (Krasner, 2010; High Rely, Inc.) 120
Table 8: Inventory of SDLC and ALM Tools 130
Table C-1: Details of Study Participants and Data Collection: Software 181
Development Methodology/Process
Table C-2: Details of Study Participants and Data Collection: Risk 185
Management Practices
Table C-3: Details of Study Participants and Data Collection: SDLC and 188
ALM Tools

viii
LIST OF FIGURES
Figure 1: A Schematic Representation of the Risk Management Process 16
(ISO, 2009)
Figure 2: Typical Hazard Analysis and Mitigation (FDA, 1999b) 25
Figure 3: Illustration of Questions Used to Establish a New Software 28
Product in the “Major Level of Concern” Category (FDA, 2005b)
Figure 4: Application of Design Controls to Waterfall Design Process 52
(FDA, 1997a)
Figure 5: Waterfall Model for Software Lifecycle Processes 57
Figure 6: V Model for Software Lifecycle Processes (USDOT, 2007) 60
Figure 7: CMMI Maturity Levels (1-5) (CMMI, 2011) 62
Figure 8: Spiral Model (Boehm, 1986) 63
Figure 9: Scrum Methodology for Software Development 65
(Scrum Alliance, 2011)
Figure 10: Details of Scrum Methodology (Agile for All, 2011) 66
Figure 11: The Evolution of Software Development Tools (Chappell, 2008a) 67
Figure 12: Cradle-to-Grave Tooling of Software Development Lifecycle 68
(Chappell, 2008a)
Figure 13: Application Lifecycle Management, ALM (Chappell, 2010) 69
Figure 14: Governance, Development and Operations Phases of ALM 70
(Chappell, 2010)
Figure 15: Details of Study Participants: Software Development 81
Methodology/Process
Figure 16: Preferences in Software Methodology Amongst Users 82
(Forrester, 2010c)
Figure 17: Hybrid Agile with Waterfall Elements at Bio-Rad Laboratories 92

ix
Figure 18: Inside an Agile Iteration at Bio-Rad Laboratories 93
Figure 19: Agile Iterations at Bio-Rad Laboratories 94
Figure 20: Details of Study Participants: Risk Management Best Practices 98
Figure 21: Assigning IEC 62304 Safety Classes to Software Items 100
at Covidien
Figure 22: Human Factors Engineering Process (AAMI, 2009) 102
Figure 23: Human Factor Activities During Design Controls 103
(AAMI, 2009)
Figure 24: Assurance Cases for Medical Devices as Described by SEI 104
Figure 25: FMEA (Covidien) 106
Figure 26: FTA as Discussed by EI, Abbott 107
Figure 27: Software Quality Assurance (SQA) at Given Imaging 108
Figure 28: Details of Study Participants: Software Development and 112
ALM Tools
Figure 29: Popular IDE Tools (Forrester, 2010a) 117
Figure 30: SCM Tool Usage Amongst Software Developers 119
(Forrester, 2008)
Figure 31: Leaders in Testing Platform Tools (Voke, 2010) 121
Figure 32: Use of SDLC Tools at Covidien 124
Figure 33: Parasoft’s ALM Tool (Concerto) for Medical Device Industry 126
(Parasoft, 2011)
Figure 34: MKS’s ALM Tool (Integrity) for Medical Device Industry 127
(MKS, 2011)
Figure 35: Waterfall vs. Agile Software Development Method 138
Figure 36: Adding Independent V&V to Agile Method 140

x
Figure 37: Agile Method’s Priority-based Approach 142
Figure 38: Agile Method Combined with IEC 62304 Risk-based Approach 143
Figure 39: Using FMEA to Identify High, Moderate and Low Risk 145
Software Items
Figure 40: Agile Software Development Method for Medical Device 148
Industry
Figure 41: Microsoft’s SDLC Tools Integrated into ALM (TFS) 153
(Malhotra, 2010)
Figure 42: Automated Software Risk Management (SRM) Framework 156
for Medical Device Industry

xi
ABSTRACT
Medical devices today rely extensively on software for a wide variety of
functions. Device manufacturers must be equipped with software-focused risk
management approaches, because software integration brings unique challenges in
safety-critical medical applications. This study explores various approaches to foster
the development of a software risk management (SRM) model throughout the
software lifecycle (SLC). A combination of interviews and other exploratory
methods including the inspection of documents and other artifacts were carried out to
characterize activities in three areas: software development methodologies; risk
management best practices throughout SLC, and software development and lifecycle
management tools. The research identified that the two most common software
development methodologies used in the medical device industry today are the
traditional Waterfall and the more recent Agile method, whose customizations are
discussed. Best practices identified as important for risk activities included the use
of IEC-62304 standard for risk-based software development, Human Factors
Engineering (HFE) methods, assurance cases and FMEA tool. With this knowledge,
a SRM framework was developed in which certain risk management practices were
implemented into the modified Agile/Scrum software development methodology.
Then, tools for software development such as requirements, configuration, build, test
and defect management, and those for Application Lifecycle Management (ALM),
were explored to suggest ways in which to automate the SRM framework.

1
CHAPTER 1
INTRODUCTION
Background of the Problem
A wide variety of clinical applications served by today's medical devices rely
on software. For example, drug pumps that dispense medications according to a
schedule and dosage that is programmed by the caregiver in a hospital setting rely on
proprietary software to ensure that the commands programmed by the user are
translated into mechanical extrusion of the medication bolus. In other situations,
software is developed as a standalone product designed to be used with a range of
devices from different manufacturers. For example, software used to plan treatments
or manage patient data can be used with a variety of hardware and computer
platforms, such as electron accelerators, control systems and patient/tumor
positioning software, in radiation therapy applications.
The medical device industry has become highly interdisciplinary in its quest
to produce new, competitive solutions for the consumer, often combining hardware
and software subsystems (Feldmann, Shull, Denger, Host & Lindholm, 2007). Many
new risks have emerged as software solutions replace hardware functions such as
switches and other electromechanical control systems, and integrate with or into a
wide-variety of medical device systems to enhance their ability to deliver state-of-
the-art technologies and complex workflow management systems in healthcare
(Hartkopf, 2003). Yet it is all too common for risk management activities to be
carried out on software using the same approaches that were traditionally used for

2
hardware, without addressing the unique characteristics and attributes of software
sub-systems.
When software solutions must be integrated into a medical device, it is
important to follow appropriate risk management activities for that software (Wood,
1999). Device manufacturers first must understand the inherent differences between
hardware and software components and establish robust software development
processes that are based on recognized engineering principles appropriate for safety-
critical systems. Risks associated with the interactions between hardware, software,
human (e.g., patient, operator), and environmental (e.g. physician’s office, surgical
suite) elements then must be mitigated in the context of the use for which the product
is intended, in order to assure that such products are sufficiently safe for use (Jones,
Jorgens III, Taylor Jr & Weber, 2002). A disciplined, well-defined risk management
process must be applied throughout the product life cycle, from product inception,
elaboration, construction, testing, and release until the product is retired. It is the
responsibility of the manufacturer to establish risk appropriate development
processes based on best practices and recognized standards in the software
engineering industry, and to provide training and tooling to their developers.
Designing safety into the software product during its development is the most
effective way of reducing defects and adverse events in its subsequent clinical use
(Cooper, 2006; Rakitin, 2006; Vogel, 2006).
Since the early 1990s, much attention has been focused on the development
of risk management tools and methodologies for medical products. Risk

3
management activities are now viewed as a required activity that must be
demonstrated as part of regulatory dossier of class II and class III devices (Burton,
McCaffery & Richardson, 2008). Class II and III devices, which have medium- to
high-risk profiles, constitute the majority of medical devices on the US and European
markets, and these commonly include software-based products. The commonly
accepted standard for the conduct of such risk management applied to medical
devices, ISO 14971, is generally viewed as the primary standard by which to satisfy
these regulatory requirements. The standard is generally used to frame risk activities
that occur across the product life cycle and are captured as essential elements of the
design history file of the device. However, this standard is a multipurpose document
designed to structure risk management activities in organizational terms for devices
of all types, from catheters to cochlear implants. It does not deal with detailed
approaches for particular subclasses of products or subcomponents of products and it
says rather little about specific tools for the conduct of software risk management
(SRM). SRM is a relatively new concept in the industry in its understanding of the
nature of risks associated with the software in the products and their mitigation (Roy,
2004). Thus industry has had some latitude in designing risk management
approaches that deal with software in accordance with its indications for use and
according to the culture of the quality and design teams responsible for its
development.
The interrelated approaches to security, quality assurance, and risk
management in software systems are viewed in terms of three historical
generations, with significant paradigm shifts between them. The first

4
generation of risk management was compliance oriented, and made the
assurance of quality straightforward in the consumer’s mind; it could perhaps
be summed up in the instruction, “buy rated products”. The second
generation saw the development of certain standardized tools for risk
assessment, and questioned the universal applicability of the first-generation
view of risk management. The software community is currently on the
threshold of the third generation, which is more encompassing, integrated,
and customizable than previous generations. Challenges for the third
generation include developing a broad perspective of risk management for
software systems, developing effective, often product specific tools, and re-
defining assurance to be based on measurable risk reduction rather than on
compliance. (Fletcher, Jansma, Lim, Halbgewachs, Murphy & Wyss, 1995).

Statement of the Problem
The current environment for software risk management is in a state of flux, as
industry and regulatory leaders establish standards and methods for software risk
management. The 1980s and 90s saw a significant trend in the replacement of
hardware by software solutions. This has placed a great emphasis on the quality,
safety and reliability of software throughout its product lifecycle. Risk management
to date has matured considerably for the management of hardware but has not shown
equivalent progress in the software arena (Bennett, Bohoris, Aspinwall & Hall,
1996). It is not clear the extent to which certain key standards are adopted, and
which specific processes, practices and tools for software risk management have
been used to aid effective implementation in different medical device companies.
Thus it is difficult to characterize what currently constitutes best practices. It is also
difficult to know how much “current” practice deviates from “best” practice without
benchmarks to assess where gaps exist or performance could be improved. Of
particular relevance to the research described here is the seeming paucity of

5
standardized methodologies/processes, practices and tools that are specific to SDLC,
and could aid risk management throughout the life cycle.
Purpose of the Study
The purpose of this research is to use a combination of interviews and artifact
analysis to explore various software development methodologies and tools, as well
as risk management practices across the software lifecycle, that are now available
and respected by the industry, and to further analyze how they can be integrated to
provide a systematic risk management framework for safety-critical, high-risk or
complex products containing software. The specific aims of the research are to:
• explore various risk management best practices that have been suggested
for medical devices and other safety-critical, high-risk or complex
products containing software across various phases of software lifecycle.
• identify the most effective software development methodology/ process
that might serve as a platform for this framework.
• develop an inventory of various software development and lifecycle
management tools most commonly in use.
• create a framework for SRM by integrating various risk management
practices into the most effective software development
methodology/process, and then using software development and lifecycle
management tools to assist with its automation and management.

6
Significance of the Study
The significance of this study takes its start from the FDA’s analysis of 3,140
medical device recalls conducted between 1992 and 1998 showing that 242 recalls
(7.7%) could be attributed to software failures. Of those recalls, 192 (79%) were
caused by software defects that were introduced during software maintenance i.e.
when changes were made to the software after its initial production and distribution
(FDA, 2002). More recently in 2006, the Center for Devices and Radiological
Health (CDRH) of FDA reported that 21% of all medical device recalls were due to
software defects and that one in three software-based products was recalled (Krasner,
2010). The view appears to be emerging that risk management activities in medical
devices have not yet incorporated a sufficiently robust and systematic system of
software risk management to ensure the safety of medical devices, particularly as
more software is integrated in legacy medical device systems, either as later add-ons
or as stand-alone software sub-systems. Studying best practices in the software
lifecycle should help to develop a comprehensive approach to risk management for
medical devices and other regulated industries. Such an effort ultimately may reduce
the risks engendered by medical product software, and improve the confidence of
both regulators and manufacturers that their products will not create unpleasant
surprises in terms of patient or operator injury, device malfunctions and recalls. A
major challenge to individuals charged with the responsibility of risk management in
the industry is the absence of a comprehensive framework to pursue this objective in
a systematic fashion. By exploring best practices, methodologies/processes and tools

7
applied during development and maintenance of medical devices containing
software, it may be possible to identify those risk management approaches that are
most applicable, practicable and comprehensive, and further, to pull them together
into an integrated framework for risk management.
Delimitations, Limitations and Assumptions of the Study
This study has several restrictions in scope that will delimit its applicability.
First, the study only concentrates on the most commonly used or emerging software
development methodologies and processes in the medical device industry today. It
may be that a lesser known or newly emerging methodology or process may be
missed. Furthermore, the medical device companies interviewed are those that are
known to have begun to implement the most popular software development
methodologies or processes and might increase the bias toward those methods.
Similarly, the vendors and tools considered as candidates for inclusion in the newly
developed framework may not give us insight into all software development and
lifecycle management tools that are available. The study may be biased because
companies that have a significant history in providing such tools (e.g. IBM,
Microsoft, HP), or are popular among their users, may be identified more easily
because of their broader reach or better marketing into the industry.
The study makes certain significant assumptions. It assumes that software
development methodologies/processes, best practices and tools can be integrated to
create a comprehensive framework for software risk management. It also assumes

8
that software development and lifecycle management tools can help in the
automation of software development processes.
The study has several real or potential limitations. First, it is almost certainly
not possible to gather and integrate all known risk management best practices into
the software risk management framework created in this study. Furthermore, the
framework that will be constructed should only be considered as an example of
execution of such risk management approaches, for demonstration purposes or as a
basis for the development of more advanced models in further studies. The study is
also limited by the capabilities of the investigator in guiding the interviews, asking
relevant questions, and analyzing the existing sources of data in literature or
presentations in various fora. His knowledge of the field may introduce additional
inherent bias about the choice of certain software development
methodologies/processes and tools, as well as the importance of certain risk
management practices that could affect his collection and interpretation of study
data.
Lastly, the other ways to construct a software risk management framework
could possibly be found in regulated environments to which medical device industry
has much in common, as they generally develop applications that are both complex
and safety critical, and they must demonstrate to the regulatory authorities that the
applicable regulatory requirements are met. The opportunities for best practices in
risk management that exist in such industries as pharmaceutical, aerospace,
automotive, defense and nuclear power industries are outside the scope of this study.

9
Definition of Terms
Application Lifecycle Management (ALM): ALM extends beyond SDLC, and
can be divided into three distinct phases: Governance, Development and Operations.
It links business management to software engineering through the use of tools that
facilitate and integrate project/portfolio, requirements, coding, configuration, build,
test, traceability and defect management (Chappell, 2010).
Failure Modes and Effects Analysis (FMEA): Failure Modes and Effects
Analysis (FMEA) is a failure analysis tool used during product and process
development for analysis of potential failure modes within a system or process,
classified by their severity and likelihood. It also helps in driving the mitigation of
unacceptable risks through various measures and considerations in bringing them
below the acceptable risk levels.
Fault Tree Analysis (FTA): Fault tree analysis (FTA) is a failure analysis tool
used to determine quantitatively the probability of a safety hazard, by analyzing an
undesired state of a system using boolean logic to combine a series of lower-level
events.
Software Development Life Cycle (SDLC): The traditional SDLC only
includes the pre-development and development phases, and ends shortly after
installation (i.e. the start of post-development phase). However, it could also imply
the whole software life cycle (i.e. SLC; see below) in some usages.
Software Development Methodology or process: A software development
methodology or process refers to the approach to structured development and

10
maintenance of a software product, as it matures through its lifecycle in various
phases. The development process runs through these phases linearly, iteratively or a
combination thereof, as characterized by several models such as Waterfall,
incremental, spiral, or agile processes.
Software development “tools”: Software programs or applications that enable
software developers to create, debug, maintain or otherwise support software
programs and applications that they develop. These tools are generally available as
enterprise application by vendors for software developers to facilitate various SDLC
activities. Examples include project, requirements, software configuration, build,
test, and defect management, as well as ALM tools.
Software Life Cycle (SLC): The phases through which a software product
passes from the time that it is conceived to the time when it is no longer available for
use. The software life-cycle typically includes the following phases:
• Pre-development: Initial investigation (conception, feasibility analysis) &
Planning
• Development: Requirements Definition, Design, Construction or Coding,
Testing
• Post-development: Installation, Operation and Support, Maintenance, and
Retirement
SLC includes SDLC (see above) as well as the post-development phase. However
SDLC could also imply the whole SLC in some usages.

11
Software Risk Management (SRM): The process of risk management as
applied to applications containing software. It is an engineering practice with
processes, practices, and tools for managing risks throughout the SLC of a product.
It provides a disciplined environment for proactive decision-making to assess
continuously what can go wrong; determine what risks are important to reduce; and
implement actions to deal with those risks.
Use errors: Use errors are defined as a pattern of predictable human errors
that can be attributable to inadequate or improper design (Pew & Mavor, 2007).
Verification and Validation (V&V): V&V is the process of checking or
testing that a product, service, or system meets specifications (verification) and that
it fulfills its intended purpose (validation). These are critical components of a quality
management system such as ISO 13485 and FDA QSR for medical devices.
Sometimes a part of V&V, e.g. validation, is performed by an independent or
disinterested third party.
Design History File (DHF): The DHF contains or references the records
necessary to demonstrate that the design was developed in accordance with the
approved design plan and the design controls requirements of FDA’s QSR (FDA,
1996b).
Quality management system (QMS): QMS refers to the organizational
structure, procedures, processes and resources needed to implement quality
management, such as one to meet compliance to the requirements to FDA’s QSR or
ISO 13485:2003 (FDA, 1996b) (ISO, 2003).

12
CHAPTER 2
LITERATURE REVIEW
Risk is an inherent feature of medical devices containing software. Whether
a medical product is acceptable for commercial distribution will depend not on the
absolute absence of risk but on assessments of the product’s “risk-benefit” equipoise.
Thus, risk management is essential for the successful introduction of a device to the
market, and continues to be essential to assure the safety and functionality of the
software and the device with which it is associated as the product passes through
subsequent stages of its life cycle, where changes are commonly introduced. In this
thesis, we are interested in gaining insight into three areas: software risk
management best practices throughout software lifecycle, software development
methodologies/ processes, and software development & lifecycle management tools.
The ultimate goal of this study is to identify an effective software development
methodology or process, into which risk management practices can be integrated to
create a framework for software risk management, using tools that help to automate
this framework. Therefore, the literature on risk management is examined and those
aspects related to best practices throughout the software lifecycle are identified.
Then various software development methodologies i.e. processes for structured
development and maintenance of a software product, that might serve as a platform
for an integrated risk management framework throughout software lifecycle are
compared. These undertakings are followed by an analysis of software development
and lifecycle management tools available to the industry.

13
Formalized Risk Management: a Short History
The systematized approaches to risk management that are now well accepted
and considered to be important in 2010 were not in evidence fifty years ago. In
1951, Juran published the first edition of Juan’s Quality Control Handbook,
considered the “bible” of quality systems at that time, and reference to risk
management is not to be found in that edition. More surprisingly, however, is the
observation that the same book, revised four times in the period between 1951 and
1999 by multiple authors, still does not contain descriptions of risk management as a
quality methodology.
The use of formalized risk management methods with a systematic approach
to assess and control medical product risk began to obtain serious attention in the late
1990s. The concepts of risk management were not new at that time; other industries
dealing with high risk products had already begun to develop methods and standards
in risk management that could be readily translated to medical product development.
For example, the Nuclear Regulatory Commission evaluated risk quite formally in its
1975 report on nuclear reactor safety, and by the early 1980s, sophisticated strategies
using tools such as multidimensional utility function approaches were used to
examine the effectiveness of regulations prospectively on the management of nuclear
waste (e.g, McCormick, 1981; Lanthrop & Watson, 1982). These tools looked at
problems with a level of systematic consideration not to be seen in medical device
industries for another 30 years.

14
A focus on risk and risk management with specific reference to the medical
products sector seemed first to become apparent in the 1990s. A flurry of
publications appeared in the regulatory literature and in medical product literature
more generally, driven by exemplars in other industries and by obligations to
implement design controls that had been introduced in the early 1990s as part of
revisions by the Food and Drug Administration to the regulations governing good
manufacturing requirements (GMPs) (FDA, 1996a). These regulations, codified in
21 CFR 820 under the new title of “quality systems regulations”, referred to risk
management as a necessary component of the documented design “output” (the term
used to describe the specifications and implementation for the final design prior to
manufacture). Further, in the preamble to this regulation, numerous references were
made to the importance of risk analysis as well as using risk-based assessment during
product design and manufacturing. The explicit identification of risk management as
part of quality assurance sensitized manufacturers to the need for risk management
activities as part of the design process, and to its importance as a regulated, and thus
auditable, part of development, to which compliance was expected by regulatory
authorities.
In the US, two documents released just prior to 2000 also appeared to be
influential in bringing attention to the need for risk management as a method to
control medical errors and product risks. The Institute of Medicine (IOM) report,
“To Err is Human: Building a Safer Health System”, identified the extent of medical
errors and injuries in the US healthcare system. Specifically, it reported that one

15
million people in the US sustained preventable medical injuries and 100,000 people
were killed by those injuries annually (IOM, 1999). In the same year, FDA
published a much quoted position paper titled “Managing the Risks from Medical
Product Use: Creating a Risk Management Framework”, whose objective was to
clarify FDA’s thinking on this topic and to encourage the active consideration of
methods to reduce product risk (FDA, 1999a).
At the same time, international organizations with an interest in medical
device safety began to develop formalized risk management methods. A very early
and short-lived European standard, EN 1441, addressed risk analysis particularly, but
was soon replaced by a more comprehensive approach introduced by the
International Organization for Standardization (ISO) in 2000. The new standard,
ISO 14971 looked at risk management as a closed-loop system for product
improvement. Its basic features are illustrated in Figure 1.
The risk management process is seen to begin with an initial phase of risk
analysis, in which the range of risks associated with the product is catalogued. In the
risk evaluation phase, the seriousness of risks is determined, often through
systematic study, and the risks are given a priority rating so that the most serious of
risks are recognized. Risk control is an action oriented step in which the risks are
then designed out or reduced to an acceptable level, usually through further design or
warnings. Finally and importantly, the adequacy of the mitigation process is
assessed to close the loop. At different levels of the activity are associated steps that
ensure communication regarding the risks. The risk management standard developed

16
by ISO is well-recognized internationally as the “gold standard” for medical device
applications, and has been revised over time, so that the current version, ISO
14971:2009 (ISO, 2009), now is considered to reflect the current thinking in best
practices.

Figure 1: A Schematic Representation of the Risk Management Process (ISO, 2009)

17
In this time-period, other international risk management standards and
guidance also emerged, such as AAMI/ANSI/ISO TR 14969:2004 – Medical devices
— Quality management systems — Guidance on the application of ISO 13485:2003
(AAMI, 2004b), and GHTF, SG3/N15/R8:2005 – Implementation of risk
management principles and activities within a Quality Management System (GHTF,
2005). The guidance document from GHTF can be considered a key document in
that it highlights the harmonization among various international regulatory agencies
including US FDA and leaders from the industry, stressing the significance of risk
management in the quality management system. It recognizes ISO 13485:2003
(ISO, 2003) as a standard for a quality management system, but extends the role of
risk management beyond product realization as required by ISO 13485, to one
including management activities of senior management, procurement, outsourcing,
acceptance activities, design and development, traceability, production and process
controls, servicing, data analysis, and corrective and preventive actions.
Similarly, AAMI/ANSI/ISO TR 14969:2004 goes beyond risk management
during product realization to include post-production risk management activities
requiring inputs from customer feedback and complaint handling, management
review decisions, handling of nonconformities, as well as corrective and preventive
actions. It highlights the need for effective communication between the
manufacturer and the customer to give a manufacturer insight into hazardous
situations so that misuses of the product by the end customer can be avoided. It
references ISO 14971 for additional information regarding risk management.

18
Risk management standards have played an important role related to
regulatory and quality activities as manufacturers seek ways to satisfy effectively the
requirements for risk management called out both by FDA regulations in 21 CFR
820 and by parallel EU regulations. ISO 14971 is one of the most harmonized
standards across various constituencies, so that satisfaction of ISO 14971 is typically
regarded as the best approach to satisfy the regulatory requirements. As a high-level
standard, it attempts to structure and stage the risk management activities of a wide
range of medical products, software included. It also provides a common language
that is understood by a spectrum of medical product engineers and production
specialists, and it allows for considerable flexibility to adopt tools and methods that
are most appropriate for the product and its types of risks. However, because it is so
clearly designed to be a high-level document, its one-size-fits-all approach makes it
challenging to implement by certain manufacturers, e.g. of devices containing
software, where a sufficient depth of understanding of software development
methodologies, tools and software risk management best practices may not be
present to conduct risk management in an effective manner.
Software Risk Management (SRM)
In the period between 1995 and 1999, a number of books and journal articles
began to focus on both the problems of assuring safety in systems in which
computers were embedded, and on tools that might be used to evaluate safety
(Leveson, 1995; Parrish, 1998; Storey, 1996; Voas and McGraw, 1998). These
articles typically were not concerned specifically with medical device software but

19
did raise awareness of problems that could be faced when using software in any
high-risk application. Computerized systems when used in medical devices can act
as a “two-edged sword” when considered in the context of risk management. On one
hand, they can help to eliminate risk associated with medical products. For example,
computerized order entry systems are viewed as key technologies with great promise
to reduce the incidence of medication errors in hospitals and pharmacies.
Computerized infusion pumps to control pain in hospitalized patients have ensured
more predictable medication management with fewer missed or poorly timed doses.
However, such computerized systems also introduce their own risks if they do not
perform according to specifications. For example, errors in the software of infusion
pumps can occur if programming errors or limitations of memory affect the integrity
of the code. Such errors have, in fact, been a real and ongoing problem. One of
many examples of problems with infusion pumps was exhibited by the Alaris SE
infusion pump manufactured by Cardinal Health. In their product, a software defect
was found in which a single keystroke was interpreted by the software as a double
keystroke (called a “key bounce”); this bounce resulted in a more than ten-fold
increase in the volume of delivered medication (FDA, 2010a). Although no patients
were hurt by this error, a costly and time-consuming recall process was required and
redesign was necessary to correct the problem. Clearly care must be taken to manage
problems such as these in order to minimize the risks posed by software, often on a
product specific basis.

20
Software risk management, as discussed above, has commonalities with
medical device risk management more generally, but also has unique features that
make the process more challenging. The typical infusion pump, for example, may
have more than one hundred thousand lines of code within which are multiple
opportunities for problems. Some specific problems may come from errors in the
actual coding of the programs, but they may also include errors introduced when
computer memory buffers are overfilled, when programs are accidentally deleted or
overwritten, or when the logical sequencing of instructions is faulty (FDA, 2010b).
Some of these faults, often characterized as bugs, can be difficult to find until they
appear after commercial distribution, usually as failures to meet performance
expectations, sometimes in a catastrophic way. Arguably the regulation of software
has been of particular concern because of the number of failures that have been seen
to date. A study of 242 software-related recalls by FDA between 1992 and 1998
showed that 192 (79%) of these recalls stemmed from errors not in the initial
software development but in later changes after the product had already been
distributed (FDA, 2002). Thus the problems are not confined only to development
but also to the maintenance of software in the field, bringing attention to the
significance of software life-cycle management. As a result, attention has been paid
in the last 15 years to the development of specific risk management methods for
software in the medical device industry.
Furthermore, with the recognition that software problems are common and
dangerous has come increased concern about the regulations to ensure safety.

21
However, regulating software is not an easy task. Problems start with the simple
need to define what is meant by software. In 21 Code of Federal Regulations (CFR)
Part 820, quality system requirements define software as a ‘component’, and extend
the definition of a ‘lot or batch’ to include a software version manufactured under
similar conditions with homogeneous quality and characteristics that contribute to
the eventual finished product (FDA, 1996b). Alternatively software that is
associated with a medical device may be considered as an “accessory”, and would
typically be regulated as if it were in the same risk category as the device itself. For
example, a software “accessory” to a cochlear implant would take on its Class III
designation, but a similar software “accessory” for a hearing aid would take on the
class of the hearing aid, typically Class II. These two classes have very different
requirements in terms of regulatory approvals and oversight. Another way to look
specifically at device software was identified by Crumpler and Rudolph:
A second definition of “accessory” is the working definition that FDA has
used over the past two years in the discussions about the agency’s software
policy. According to this definition, a software accessory to a medical device
either accepts data from the user and modifies it for input to a medical device,
or takes data from a medical device and modifies it for presentation to the
user. (Crumpler & Rudolph, 1997).

In Europe and Canada the definition of software also lacks clarity. European
Union’s Medical Device Directive (MDD, 1993) offers broad definitions that seem
to include software systems as an aside: “…'medical device' means any instrument,
apparatus, appliance, material or other article, whether used alone or in combination,
including the software necessary for its proper application…” or “Software, which

22
drives a device or influences the use of a device, falls automatically in the same class
[as the device]”. The Canadian Medical Device Regulation (CMDR, 1998) does not
offer a definition for software, but stresses in its discussion of the validation of
software: “If a medical device consists of or contains software, the software shall be
designed to perform as intended by the manufacturer, and the performance of the
software shall be validated”. CMDR further includes software within the scope of
various types of devices containing it, such as an active device intended to emit
ionizing radiation, an active therapeutic device, an active diagnostic device, an active
device intended to administer/withdraw drugs/body fluids/other substances to/from
the body, and an IVDD (In Vitro Diagnostic Device).
Software can put regulators in a difficult position because comprehensive
regulation has been problematic to develop. Regulators appreciate the importance of
streamlining regulations to avoid unnecessary fractionation and overregulation that
might unnecessarily impede the developmental path of important new technologies,
yet they must ensure sufficient guidance and oversight that problem products are
recognized and failures are minimized as part of the regulator’s responsibility to
public health. The concern to keep regulations within a single cohesive framework
requires that developers rely instead on more informal sources for specific guidance
relevant to the unique challenges of software. This requirement was expressed by
FDA in its preamble to Quality Systems Regulations (61 Federal Register (FR)
52602) (FDA, 1996a) when it stated: “FDA believes that sufficient domestic and

23
international guidelines are available to provide assistance to manufacturers for the
validation of software and risk analysis.”
If specific regulations for medical software are hard to find, then what other
mechanisms exist to assist medical device manufacturers in their efforts to develop
best practices for software risk management? Typically three sources of information
are accessible to assist such efforts. First are guidance documents and other types of
advice authored by the US Food and Drug Administration, or by comparable bodies
in other constituencies, in which the regulatory agency attempts to illustrate what
they see as appropriate practice. These types of guidance are more flexible and easy
to update than regulations, so that they are easier to change as the field evolves. This
sort of regulation by guidance is often referred to as “soft law” (FDA, 2010c).
Second are a growing number of voluntary standards that have been promulgated by
international standards-setting bodies and task forces that have both private and
public sector representation. Third are publications written by academics and
industry experts to address methods and consequences of certain approaches to
software development and risk management. These sources of information were
searched for relevant literature for following three areas of study: software risk
management best practices throughout software lifecycle; software development
methodology or processes that could be used to base a lifecycle model of software
risk management, and software development & lifecycle management tools that
might help to automate or simplify this integrated approach.

24
Risk Management Practices Through the Product Life Cycle
An important contribution of the more recent literature has been the growing
recognition that the risk management must be practiced throughout the software life
cycle. Risk management, like software development, has an orderly series of steps
that ensure a controlled approach, and these two sets of activities must be integrated.
Thus an extensive literature dealing with medical products and other safety-critical
products is reviewed to the extent possible, with an aim of identifying current best
practices in risk management.
FDA Guidance and International Standards
FDA has become more acutely aware of the challenges that software can
pose, and this is reflected in several guidance documents related to risk management
issued over the past 15 years. The first and possibly most influential document was
issued in June, 1997 and updated in Sept, 1999 to its current form: “Guidance for
Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in
Medical Devices” (FDA, 1999b). In this document, the concepts of risk analysis and
control were explored in some detail, and an overarching system of risk prioritization
was enunciated that defined software by “level of concern”. Software products with
major levels of concern before mitigation were expected to undergo more scrutiny
than software products classified at a moderate or minor level of concern prior to
mitigation. Further, the guidance specifically addressed the need for a
comprehensive risk management approach: “The manufacturer is expected to

25
perform an OTS Software hazard analysis as a part of a medical device (system)
hazard analysis.”
Further, it proposed a step-like plan for documenting the management of risk
(Figure 2) that had many similarities to the more general risk management
approaches in ISO 14971 shown previously in Figure 1.

Figure 2: Typical Hazard Analysis and Mitigation (FDA, 1999b)

26
The guidance document also considered the level and type of documentation that
was expected to justify the safe use of off-the-shelf products, and introduced the very
important concept of life-cycle management by discussing software changes or
obsolescence after its initial release for use.
At about the same time, in a second document titled “Design Control
Guidance for Medical Device Manufacturers” (FDA, 1997a), the challenges of
integrating the risk management process into the design control process were
discussed. This was particularly useful because typically the bulk of documentation
related to early-stage risk management activities must be integrated with other design
control activities. However, the guidance is not specific about how this integration
should be done, and the manufacturer is given considerable latitude to establish a
system that makes sense in the context of the product under development. This
flexibility can be useful, but it also can result in less-than-optimum risk management
if a company’s employees are not well-trained in risk management principles and
tools.
Later in 2005, specific issues regarding the safety of networked medical
devices containing off-the-shelf software were further explored in a guidance
concerned with privacy and integrity issues under the title, “Guidance for Industry -
Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS)
Software” (FDA, 2005a). This guidance discussed vulnerabilities of medical devices
to cybersecurity threats such as viruses and worms as well as threats posed by
unauthorized access to the network or the medical device connected to it. The

27
guidance attempted to address and recommend mitigations to deal with cybersecurity
vulnerabilities. It also presented the need for software patches or software
maintenance activities to address such risks.
Like “Guidance for Industry, FDA Reviewers and Compliance on Off-The-
Shelf Software Use in Medical Devices”, another 2005 guidance document titled
“Guidance for the Content of Premarket Submissions for Software Contained in
Medical Devices” (FDA, 2005b) expanded on the classification of software
according to level of concern, with greater scrutiny directed at software with
moderate or major levels of concern. It emphasized the need to attend to the level of
concern early, by saying:
Level of Concern refers to an estimate of the severity of injury that a device
could permit or inflict, either directly or indirectly, on a patient or operator as
a result of device failures, design flaws, or simply by virtue of employing the
device for its intended use. We recommend that you describe the role of the
software in causing, controlling, and/or mitigating hazards that could result in
injury to the patient or the operator, because this is also a factor in
determining the appropriate Level of Concern for your device.

It provided a series of questions intended to help the manufacturer to determine the
level of concern, as shown in Figure 3.

28
!
Figure 3: Illustration of Questions Used to Establish a New Software Product in the
“Major Level of Concern” Category (FDA, 2005b)

Another important guidance document, “General Principles of Software
Validation; Final Guidance for Industry and FDA Staff” (FDA, 2002), drew attention
to Good Software Engineering Practices. In this document, the high-level concerns
about risk identification and management are complemented by discussions of

29
specific practices such as incorporating human factors or ergonomic design
principles into software development:
Use error caused by designs that are either overly complex or contrary to
users' intuitive expectations for operation is one of the most persistent and
critical problems encountered by FDA. Frequently, the design of the software
is a factor in such use errors. Human factors engineering should be woven
into the entire design and development process, including the device design
requirements, analyses, and tests.

An FDA guidance document that deals exclusively with human factor
engineering, “Medical device use safety: Incorporating HFE into risk management”
(FDA, 2000), is also available (revision in progress). FDA also works with
manufacturers to help ensure the application of human factors engineering to the
design of new products as well as to post-market surveillance of currently marketed
products (FDA, 2011).
However, specific and recent best practices that can be used to carry out risk
management are not typically found in most FDA documents. Therefore, the
identification of those practices as employed by the industry to carry out risk
management activities must be sought elsewhere. For example, an idea which can be
considered to demonstrate the safety of a system is through the use of “Assurance
Cases”, suggested in a report from National Research Council, a private nonprofit
institution that provides science, technology and health policy advice under a US
congressional charter (NRC, 2007). An assurance case contains a claim that a
system is acceptably safe, secure, and reliable in a given context as demonstrated by

30
its auxiliary evidence, so it links the claim to the evidence with a supporting
argument.
Several international standards (e.g. ISO 14971) throughout the evolution of
risk management were discussed earlier in this chapter. There have been additional
international standards on risk management specific to medical devices containing
software. The Association for the Advancement of Medical Instrumentation (AAMI)
has been an important body for the development of standards related to medical
product software. Two of their reports in the early 2000s deserve special attention.
First, AAMI SW68 (AAMI, 2001) was created in 2001 to fill gaps in ISO 14971
with regard to the specific needs of software development. A few years later this
document was complemented by technical information report, TIR32:2004, titled
“Medical device software risk management” (AAMI, 2004a), that attempted to
marry concepts of risk management with considerations of the product life cycle, as
will be considered in more detail below. The document provided a working
framework for the practitioner that had previously been difficult to find.
Information presented in SW68 and TIR 32, together with ISO/IEC 12207,
served as the basis for a next-generation standard, IEC 62304, “Medical device
software – Software lifecycle processes”, that now has been harmonized across other
organizations and has been renamed ANSI/AAMI/ISO 62304:2006 (IEC, 2006a). It
essentially replaces the ANSI/AAMI SW 68:2001, and further assists the
manufacturer in finding integrated solutions for software risk management that is
tied to the product life cycle. IEC 62304 assigns following software safety “class” to

31
software “system” and software “items” according to the possible software hazard
effects on patient, operator, or other people resulting from a hazard to which the
software system/item can contribute: Class A, if no injury or damage to health is
possible; Class B, if non-serious injury is possible; or Class C, if death or serious
injury is possible.
IEC 62304 is perhaps the most widely referenced and useful risk-based
software lifecycle standard in medical device industry today. It is also recognized by
FDA as a way to ensure a set of “simpler and more uniform expectations” (Jordan,
2006). It specifies the importance of respecting the product life cycle, and
recognizes that software may be either stand-alone or embedded in a device. It
draws attention to the importance of maintenance activities as well as development
activities in the risk management framework, and outlines helpful supporting
processes (Larrick, 2007). There are other AAMI/ANSI standards available such as
those for human factor engineering e.g. ANSI/AAMI HE 74:2001 – Human factors
design process for medical devices (ANSI, 2001), AAMI HE 75:2009 – Human
factors engineering: Design of medical devices (AAMI, 2009), and ISO/IEC
62366:2007 Ed 1, Medical devices – Application of usability engineering to medical
devices (IEC, 2007) which includes HE-74 as annex and is currently under revision
(expected 2014).
Continuing further afield, IEC 60601-1-6 Medical Electrical Equipment –
Part 1-6: General Requirements for Safety – Collateral Standard: Usability (IEC,
2010) is an international standard that examines engineering approaches to usability

32
testing for medical electrical equipment, to assess and mitigate risks caused by use
errors during correct or normal use (although abnormal use is not considered, but the
same process can be used to identify them). It outlines methods to study various
ergonomic and human-factors concerns in the design process, with advice to avoid
confusing buttons, ambiguous icons, and other design flaws that ultimately lead to
operator errors.
IEC 60601-1-6 is also the basis for another usability standard, IEC
62366:2007 Medical devices -- Application of Usability Engineering to Medical
Devices (IEC, 2007), that is used more broadly and is anticipated to replace IEC
60601-1-6 in the near future. Like IEC 60601-1-6, its approach is also user-centric,
but it expands the scope to include all medical devices and not just electrical devices.
FDA already considers IEC 62366 as a Recognized Consensus Standard, and has
issued a list describing the minimum documentation that must accompany any
declaration of conformance to the standard (FDA, 2009). If the usability engineering
process detailed in these international standards (i.e. IEC 60601-1-6 and IEC 62366)
has been followed and the acceptance criteria proposed in the usability validation
plan have been met, the residual risks associated with usability, as defined in ISO
14971, will be presumed to be acceptable, unless objective evidence exists to the
contrary.
Other Literature
A comprehensive framework for risk management activities across various
phases of the software life cycle remains relatively undeveloped in the area of

33
medical software systems or medical products containing software. Nonetheless, the
rather unsystematic literature that does exist identifies a variety of risk management
activities that might be carried out throughout software lifecycle, and also discusses
the challenges of developing an integrated system linking them together.
The pre-development phase.
Before development activities begin, a software development team is
expected to conduct an investigation in which the product is conceptualized and its
feasibility is explored. This investigation includes: 1) initial risk assessment, and 2)
project management, starting with planning of subsequent lifecycle design activities.
1. Initial risk assessment.
Risk assessment and analysis at this stage includes the review of all
applicable policies, procedures, practices, regulations and standards that will be
important for the product. It also includes specific consideration of risks known in
the past to be associated with this type of product and with the intended environment
in which the product will be deployed. A systematic approach to risk assessment and
analysis performed early in the SLC will consider a range of reliability, safety, use
errors, user errors and resource issues. It will provide the framework on which
project management can build a systematic plan to control and mitigate serious risks
from the beginning of the life cycle (Cooper, 2006).
2. Project management.
Based on the risk analysis, the team charged with managing the software
project can determine the scale of activities to be employed, and estimate the levels

34
of effort necessary for quality assurance oversight. The project manager must
configure various activities in such a way that adequate functionality, quality
assurance, and safety can be assessed and achieved within the available resources; if
such resources are not allocated, he or she must identify and justify the resources
needed for this activity, a perceived “net negative”. Matsuo (2000) further adds:
Cost overruns, schedule slips, and projects with fewer features or functions
than originally specified are some of the difficulties that the software
community faces in almost all software projects. …. A disciplined and
systematic risk management tool can be utilized to assess risk in incremental
software development projects from cradle to grave, can be applied with
limited resources, and is adaptable and be flexible enough to be used on all
software intensive projects” (Matsuo, 2000).

Thus a good project manager will ensure that clinical experience is factored into the
development of this project, active support is leveraged from management,
organizational changes are made as necessary, and appropriate resources and skill
sets of personnel are obtained (Mallory, 1993).
The development phase.
The development stage is a relatively long and complex phase especially if
the software under development must be coded de novo. It is divided into a series of
largely sequential activities: definition of requirements: 1) requirements and use
cases, including Human Factor Engineering (HFE), and exploration of user and use
errors; 2) design, including software design, specification and architecture; 3)
construction (often called coding); and 4) verification & validation (V&V) activities,
including the evaluation of software metrics to measure coding progress and
software quality.

35
1. Requirements and use-cases.
The development phase starts with the identification and documentation of
requirements through consultation with end users. The identification of requirements
is typically considered by regulatory agencies as the initiation of a controlled design
process. The requirements constitute the design inputs that drive the development of
the software (Subramanian, 1995). The most common uses of the software are
captured in documented “use-case scenarios” against which the developed software
will eventually be tested. Tsai et al. (1997) comments that “developers must be
cognizant of the impact on reliability and safety which are introduced through
directly garnering requirements from end users” (Tsai, Mojdehbakhsh, &
Rayadurgam, 1997). This might be done by surveying or interviewing users, holding
focus groups, or beginning to examine scenarios to show how the software will be
deployed by a particular group of users. This important activity sets the stage for
subsequent product development. It requires analysts who are specifically
experienced in the development of requirements. Thus it is not unusual to consult
marketing and user-experience teams separately from the software development team
so that system requirements are documented in a more comprehensive manner
(Cooper, 2006).
Mojdehbakhsh et al. (1994a) further stresses the importance of having a
process for safety analysis while functional requirements are developed
(Mojdehbakhsh, Subramanian, Vishnuvajjala, Tsai, & Elliott, 1994a). The most
commonly used tools to identify the potential cause and magnitude of these risks,

36
and to assess effectiveness of mitigation efforts are Failure Modes and Effects
Analysis (FMEA) and Fault Tree Analysis (FTA). If these tools can be introduced at
the earliest stages of development and then used throughout the life cycle, especially
with other approaches such as user-centric design approaches and compliance to
usability standards, the safety profile of the product is greatly improved (Israelski &
Muto, 2004). Although either FMEA or FTA can be used for risk analysis, they
complement each other and optimize risk analysis when used together. One can start
with the FMEA and then use FTA on the highest risk failure modes. Also, FTA is
more suitable for quantitative analysis in which the probability of a failure state is
calculated. Therefore, FMEAs are low-cost and easy to use for broader risk
assessment, and FTA can be leveraged for the worst failure modes.
In addition to factoring the needs of end users into the requirements, the
potential for errors that are attributable to the way that a device is used (use errors)
must also be considered. Manufacturers have traditionally blamed end-users for the
adverse events caused when their devices are used incorrectly, but poor device
design may account at least in part for such incidents. Use errors fall into two
categories: errors that relate to “what” the user needs to do, and errors that relate to
“how” the user will be able to do it in the environment where the device is employed.
Conditions associated with the ease of use, safety of use, and efficiency of use are
designated as “human factors”. These considerations include user interface design,
cognitive abilities of the user, visual and auditory conditions in the environment,
ergonomics as well as user experience. As a result, regulators typically demand that

37
device manufacturers thoroughly explore the user interfaces/interactions and user
environment when they develop requirements, and start this exercise as early in the
development cycle as possible (Ward & Clarkson, 2004).
In software development, it is important to consider when a certain feature or
executable command/operation can be potentially “misused” accidentally. One
example of such a problem that caused great patient harm was seen in a series of at
least six accidents that occurred in 1985-87. In this situation, patients received
approximately 100 times the intended dose of radiation, when a series of systemic
failures, including software problems combined with human errors in operating a
Therac 25 Radiation Therapy System, resulted in a catastrophic malfunction
(Leveson & Turner, 1993). The accident resulted in the death of three of the six
patients as a direct consequence of the radiation overdose. Such incidents have
become standard case studies in medical devices and software engineering. They
bring into sharp focus the need for risk analysis as early as possible in the
development phase, and the need for that analysis to include considerations of human
factors engineering in reducing user as well as use errors in medical device industry.
As Blake summarized with regard to user and use errors:
Mistake proofing and redundancy in design are becoming essential features
of the validated environment. Properly applied and embraced, they will
further increase the reliability of machines and the quality of the products
emerging from the medical device industry. More importantly they will help
focus validation on machine enhancement and reliability and reduce the
dependence on operator intervention and vigilance in ensuring desired quality
levels are achieved. They are the only way of eliminating the transient fault
and aberration in performance that has arisen from the complexity of modern
machine design. (Blake, 2003).

38
2. Design.
Once requirements have been approved, design specifications are developed
to guide software engineers “how” the software will be developed to meet the
requirements. They contain all of the design considerations that a software engineer
will take as input to the exercise of writing software code. Design specifications are
typically documented, formally reviewed and approved prior to software coding.
Previous studies have identified that many software problems result from bad
design (Wallace & Kuhn, 1999). At this stage, then, risk assessment is typically
revisited, and risk identification can be formalized into a more careful process in
which the likelihood and severity of the risks can begin to be quantified and explored
experimentally if necessary. Complex and high-risk applications such as medical
devices demand a particularly thorough analysis of development and safety
considerations by engineers designing the software (Jorgens & Greenbaum, 1988).
At the same time that design specifications are developed, robust software
architecture must be modeled by the engineers. This activity is important because the
architecture will provide the essential skeleton for the software code. Risk
assessments and safety considerations made at this fundamental level of software
design are useful, but few risk management techniques based on design analysis have
been suggested in the published literature. However, Ramachandra et al. (2006) has
discussed a structured framework using software architecture analysis and design,
primarily for the use of the software architect in risk management (Ramachandra,
Haeng-Kon, Byeongdo, Yan & Lee, 2006). This technique provided an effective

39
framework for the developers, contractors, consultants and managers to architect
secure systems. The risks detected by his technique were unique and complementary
to those detected by other techniques such as software risk evaluation (SRE) tools.
3. Construction/coding.
Software developers start coding as soon as the architecture and lower level
specifications are in place. Coding refers to the set of instructions written in a
programming language (e.g. C, C++), that are compiled to make a computer
program. A typical program can have thousands of lines of code. Thus, managing
risk at this level is critical; it is at this level that a software designer will have to fix
an issue found later in development (for example, during V&V) or, even worse, in
the field after an adverse event has occurred.
Risk management activities applied at the level of software coding typically
differ from those performed at higher levels of system construction. Here it is
primarily directed at risk control, often by analyzing code to ensure that it was
written in a way that delivers a safe and reliable end product when assembled into a
system. This work can be done in many ways:
Good coding practices: Training software engineers on the adopted
procedures for good coding practices during code construction. Mentorship is key to
ensuring that such practices are established and used across the various software
teams (Cooper, 2006).

40
Unit/module, integration and system level testing: Using various test
techniques at code level and at sub-system and system levels (see Software V&V
section below).
Manual code/peer reviews: Authorizing one team of engineers to review the
software developed by a different team/member. Peer review of software code is not
an alternative to other forms of software verification, but is seen as a complimentary
and necessary activity to improve device safety, performance and maintainability
(Koru, El Emam, Neisa & Umarji, 2007).
Static code analysis: Using computer programs (instead of humans) to
conduct automated code reviews. Static code analysis is typically more invasive and
exhaustive than manual reviews, and looks for subtle errors that may not be detected
in manual reviews. This relatively new and powerful analytical technique examines
the source code for indications of potential design defects during code construction
when such issues can be addressed most efficiently and effectively. It does not
require that the software run in a real or simulated environment, which typically can
only be provided near the end of the development phase after most software
validation has been conducted.
Static analysis techniques operate by tracing all possible execution paths
through the software. The amount of time taken to process this labor intensive
activity is greatly reduced to the acceptable levels by a number of commercially
available static analysis tools (FDA, 2010a). For example this method is effective
for detecting “buffer overflow”, an undesirable state in which information provided

41
to the program exceeds the capacity of the memory assigned for it by the operating
system. In such a scenario, information is lost due to the overflow or overwriting of
data and instruction in the too-small memory. When this data is needed as an input to
another part of the program, that subsequent part of the program may not have the
correct information to perform its functions, and this can cause a generalized device
malfunction.
4. Software verification and validation.
The Software Verification and Validation (V&V) phase is the final gate
through which a software product must pass before release to the end user. Software
verification involves testing to confirm if the product was “built right”, and is done
by examining the ability of the software to perform according to lower-level design
requirements and specifications developed to guide software coding. Software
validation involves tests with the objective to prove “if the right product was built”,
and tests the product to ensure that it meets higher level requirements established
when user needs were assessed (Sommerville, 2000). At least some of V&V
activities, especially validation testing activities at the end of the development phase,
are conducted by different individuals from those who coded the software, to assure
independence of the evaluative functions (Mallory, 1993). The degree of seriousness
with which V&V activity is approached depends on the criticality and risk posed by
the software, and is typically correlated with its “level of concern”, as defined
earlier.

42
Software V&V is an integral part of the overall software quality assurance
(SQA) process. However, V&V is a particular activity in the development phase of
life cycle, while SQA exercises broad oversight that involves all phases of life cycle
including, but not limited to, planning, traceability, configuration management,
defect management, and post market surveillance. SQA ensures safety, reliability
and maintainability of software processes and products by ensuring conformance to
all internal (e.g. company procedures related to design controls, and user, design and
system requirements set forth by the development team) and external requirements
(e.g. all applicable standards, regulations, and customer requirements) (Cooper,
2006).
Recently, attention has been directed at not only the qualitative aspects of
software development, but also the concurrent development of software metrics, i.e.,
quantitative measures of some aspect of software structure or performance that can
be used to help manage the design or evaluation process. Software metrics can be
sub-classified as either product or process metrics (Li, 2000). Product metrics derive
from the product itself, and might include for example, the number and type of
defects found in the device at various stages of the SLC, whereas process metrics are
those associated with the process, for example, the number of test cycles needed to
find defects and validate their correction before a product is released to the field. Liu
et al. (2003) further added a third dimension to this collection of metrics by adding
“organization metrics” to product and process metrics in the context of discussing a
particular piece of software (a customizable early warning system using fuzzy logic).

43
His analysis involved using these three dimensions to quantify the software and its
development and to predict associated risks in very early stages of development (Liu,
Kane & Bambroo, 2003).
Liu et al. (2003) have not been alone in exploring the usefulness of metrics to
sharpen the assessment of quality attributes or to evaluate whether specific
performance goals have been reached. For example, Nagappan (2004) discussed the
dichotomy of internal metrics (derived from the “product” itself, e.g. the number of
lines of code) and external metrics (the behavior of the product, e.g. number of
defects found in a test), and emphasized the need for evidence of a close relationship
between the two. Akingbehin (2005) explored the use of metrics based on statistical
methods such as the Taguchi approach originally developed for the control of quality
on the manufacturing floor, and six-sigma methods, also used to improve
manufacturing processes. Akingbehin’s approach measures software quality using a
set of numerical software measurements or metrics. It defines software quality in
terms of “loss imparted to society” after its release to the field, for example, through
failures to perform according to specification, and has showed good correlation to
other popular metrics in the area of software quality. Mizuno et al. (2002) developed
a statistical model to determine the amount of testing effort needed to assure certain
degree of field quality by including design, review, and test and debug activities
(Mizuno, Shigematsu, Takagi & Kikuno, 2002). Similarly, Sharma and Jalote
(2006) found that in software products, the failure rate often decreases after
installation, eventually reaching a steady state, and proposed a new metric called

44
stabilization time, or the time taken for the reliability of the product to stabilize after
its installation. Such metrics can provide significant value to the product
manufacturer and users when they try to compare different products, but they are
intended to supplement and not replace other metrics measuring reliability (Sharma
& Jalote, 2006).
Metrics can be used to evaluate performance but can also be used to probe
how more basic or structural features of the software can impact performance and
safety. A software system with a well developed software architecture and modular
design can greatly facilitate the task of measuring quality at any stage of system
abstraction, as various modules or components come together throughout the
software life cycle to form a system. Visaggio (1997) presented metrics to monitor
changes in the quality of the system during its life-cycle and to determine which
level of abstraction caused the degradation of the system, to enable timely actions to
counter any such drop in the quality (Visaggio, 1997). Blundell et al. (1997)
discussed similar metrics that can predict an optimum modular structure comprising
the software system (Blundell, Hines & Stach, 1997). Similarly, Arhire and Tanase
(1995) discussed “complexity indicator” of software product at every stage of
software life cycle, together with other software quality indicators such as clarity,
maintainability, viability, adaptability, integrability, testability, efficiency, safety in
use, stability and completeness (Arhire & Tanase, 1995).
Owing to the subjective nature of relationship between various metrics in the
SLC processes, research into the ultimate value of metrics for managing software

45
quality has been relatively modest (Lee & Choi, 2000). Each software product is
different, and so may be the process used when developing the product. Thus, while
most SLC models are similar across industries including the medical device industry,
metrics generally are not. A thorough understanding of various associated factors
and interrelationships that might be specific to the particular use and design of the
software is needed to develop a meaningful metric for that product and its processes.
Only then will software metrics be able to capture essential features of the software
and predict its performance.
Appreciation is growing for the view that the initial stages of the software life
cycle are critical to avoid expensive mistakes that must be fixed after software
release. It is at this stage where requirements are set, and where incomplete,
ambiguous and erroneous user requirements can lead to ambiguity and uncertainty in
the development phase as software developers design the software. Such uncertainty
often results in errors in writing software code. The effect of such hidden errors is
not only detrimental to the current cycle of software development but it becomes
magnified for each change made thereafter, i.e. during software maintenance when
changes of already erroneous requirements may compound to escalate unreliability
and risk. Thus, the considerations made initially in the software life cycle have the
lasting effects not only in software development but also in maintenance activities
(Schneidewind, 2001).

46
The post-development phase.
The post-development or “Maintenance” phase includes “installation” of the
developed software for the real world operations where it is supported until its
obsolescence or retirement. Software maintenance refers to changes made to the
software product after its initial release to the end customer. The need for such
change stems from several factors such as changes in the hardware with which the
software works, change in other associated software or operating systems, or changes
in the needs of the users. These changes ensure that the software can evolve with the
environment in which it is used (Webster, de Oliveira & Anquetil, 2005).
Additionally, requirements may be altered or added if changes occur in the way that
the software is used (e.g. a change in user workflow) or the new needs of a user (e.g.
ability to perform an operation which was not possible before). Unanticipated failure
modes or bugs also drive software changes. With all these reasons for change, it
comes as no surprise that software maintenance is typically the most expensive
activity of the SLC, consuming as much as 90% of the cost of a typical software
project (Pigoski, 1996). It is important to recognize that software maintenance is not
just about correcting software defects or anomalies. It depends on a rational
assessment of changes in the device and its use, and is central to risk management.
In essence, software maintenance “relives” the original software development
process over and over again. Each iteration and incremental change can challenge
the underlying risk and safety of the product. Each change that is made in a one part
of the software program can perturb the function of another part of the program even

47
if that affected part was not touched. Perhaps for this reason, software changes made
to the product after release are a major source of concern for regulatory agencies
because they can have significant safety implications (FDA, 2002). However, even
though software maintenance can pose challenges and risks atypical for the more
systematized software development process, the literature on the controlling risk
during software maintenance is scanty, and the risk management techniques and
tools required to address this challenge are underdeveloped (Webster et al., 2005).
Additional challenges arise when software changes must be made to “legacy”
systems that may have been created a decade or more ago, when best practices,
methodologies, tools and techniques in software engineering were quite primitive.
Further, regulations and standards governing quality systems and risk management
were relatively underdeveloped. Thus legacy systems often lack design, testing and
risk management documentation, and the documentation that does exist may be
incomplete or outdated (Charette, 1997; Pigoski, 1996). Thus, new changes to these
legacy systems may be compromised. Often, software testing undertaken to verify
the success of a new change will uncover defects in that software which may have
been present for many years and may have no relation to the change under study.
Further, if documentation is lacking, a software developer with no prior knowledge
of a portion of the code may inadvertently make changes that would damage the
program at some other location or level. A tester may not have a full suite of test
cases to perform regression testing normally applied to ensure that the unchanged
parts of the program remain functional.

48
Regulatory agencies require that software safety and documentation are
proven to be compliant with current requirements, in order to keep the legacy
products on the market or make changes to them. Therefore, most manufacturers
whose legacy products rely on software are interested in ways to ensure compliance.
Base-lining the system may mean that missing documentation must be rewritten and
full V&V must be carried out to ensure that the overall system is compliant with
performance specifications. All changes to improve the structure and performance
of the software must be documented in the design history file, thereby retrofitting
software safety into medical devices (Mojdehbakhsh, Tsai, Kirani, & Elliott, 1994b).
A technique employed by Tsai et al. (1998) at Guidant-CPI to ensure system and
software reliability in safety-critical systems is known as “Ripple Effect Analysis
(REA)” technique. The REA is an iterative process of analyzing and eliminating
side effects due to changes caused by the ripple effect i.e. the phenomenon of a
change to one part of a software artifact affecting other related parts. REA ensures
that all of the intended changes during software maintenance were actually made
without undesirable side-effects to the software. This technique can be seen as a
complimentary to regression testing, where the emphasis is on ensuring that the
changes that were not intended to be made were actually not made during software
maintenance (Tsai, Mojdehbakhsh, & Zhu, 1998). Tsai et al. (2001) later suggested
scenario-based functional regression testing, which used test dependency and
traceability information, combined with REA to identify all directly or indirectly
affected test scenarios, so that test cases could be optimally selected for regression

49
testing. The test scenarios were first represented in a template model with test
dependency and traceability. Test dependency information helped to detect the
affected scenarios, while traceability helped to find affected components and their
associated test scenarios/cases for regression testing (Tsai, Bai, Paul, & Yu, 2001).
Regulators like FDA are obviously concerned about device failures in the
field. Medical devices are meant to be safe and effective, to save lives and improve
the health of individuals suffering from an underlying medical condition. Inspection
of FDA records between 1999–2005 has shown that one in every three medical
devices using software has been recalled because of failure in the software. Further,
11.3% of all FDA recalls are attributable to software failures. As more and more
products have incorporated software in medical devices, an increased number of
software failure recalls has been recognized as a troubling trend (Bliznakov, 2007;
Baker, 2003; Baker, 2004; Thomas, 2006).
The gradual development of a database of product problems in regulatory and
company adverse events files can shed light on places where the most common risks
from software are to be found. Wallace and Kuhn (1999) analyzed 342 software
related failures of medical devices that led to recalls, based on available information
regarding the problem and underlying root causes responsible for the recall.
Problems such as alarm failures, data loss or corruption, loss of device functionality,
and inconsistencies with display units were viewed as the “symptoms” of failures.
The most common symptoms were compiled and trended. Similarly, a list of “root
cause” fault categories or types was compiled and trended. The most common faults

50
types were found to be attributable to logic (43%) and calculation (24%) failures.
Based on these results, several recommendations were made to prevent and detect
such faults. For example, logic faults could be greatly reduced by using methods for
improved handling of various conditions, assumptions, and interactions among
functions. Calculation faults could be addressed by ensuring that correct calculations
are executed by approaches such as verifying that correct algorithms are specified,
and that programmed operators and increments are correct.
In other developed countries, regulators are also concerned with tracking
adverse events and equipment malfunctions that have the potential to damage
patients and users. Just as mandatory reporting is required under rules for Medical
Device Reporting (MDR) in US, Mandatory Problem Reporting in Canada, and
Incident Reports and Recalls (Article 10 of MDD; Vigilance Guideline MEDDEV
2.12-1 Rev.5) in the European Union (EU) are needed for adverse events involving
serious injury or death, or even the potential for serious injury or death, of patients or
personnel working with the device. Similarly, the World Health Organization
(WHO) has also identified this issue as a high priority through a number of actions
and recommendations. Emphasis is placed on methodologies and frameworks to
detect adverse events and errors (Simmons, 2001; Bliznakov, Pappous, Bliznakova
& Pallikarakis, 2003; Brewin, Leung & Easty, 2001; Murff, Patel, Hripcsak, &
Bates, 2003; Roumm, Sciamanna & Nash, 2005). Ironically, for the case of software
errors, electronic tools and software based bioinformatics methodologies are

51
considered as important ways to improve the largely manual and intuition driven
analysis of adverse events that had typically been standard practice in the past.
Software Development Methodologies/Processes
There are several practices listed above that lend themselves to risk
management at various stages of the SLC. However, without a way to integrate
these activities systematically into the software development process, they will
remain a fractionated set of stand-alone activities that may be incomplete, redundant
or inappropriate. To build a more systematic risk management model for the full
SLC, it is necessary to integrate the practices within the process, or methodology,
that is being used to generate the software. There are different software
methodologies in use today, so their review is important in order to seek information
on the best method for the development of SRM model envisioned in this thesis.
“Methodology” and “process” are two terms, often used interchangeably, to
describe the structured approach taken to develop and maintain a software product as
it matures through a lifecycle. It is characterized by a sequence of phases from the
time that it is conceived to the time when it is no longer available for use.
FDA Guidance and International Standards
The need for a structured methodology is not just convenient from an
industry point of view; it is a regulatory requirement in order to meet expectations
for product design. FDA states in regulation 21 CFR Part 820, “Quality System
Regulation under Subpart C - Design Controls” (FDA, 1996b) that medical devices
must have a controlled design process that includes several activities throughout the

52
design lifecycle. A detailed document to help medical device manufacturers with
design control process was provided by FDA in “Design Control Guidance for
Medical Device Manufacturers” (FDA, 1997a). Design control was illustrated
through the use of traditional Waterfall method, as shown in Figure 4. In this
method, design has sequential stages in which requirements (often called design
inputs) are developed, and a design process is organized that has specification-setting
and implementation components. The design is then verified and validated against
requirements and intended user needs, before its transfer to production. Design
reviews are held at various points to assure that the feedback is appropriate and
sufficient. A concurrent engineering model involving engineering, production,
service and other departments is highly encouraged.

Figure 4: Application of Design Controls to Waterfall Design Process (FDA, 1997a)

53
The Waterfall model for design controls illustrated by the FDA guidance is in
many ways similar to the Waterfall methodology traditionally used in the medical
device industry for software production. However, FDA does not require that a
company adopt a particular software development methodology, as may be implied
by the reference of a sequential Waterfall-model in their guidance:
The medical device industry encompasses a wide range of technologies and
applications…. Given this diversity, this guidance does not suggest particular
methods of implementation…. Rather the intent is to expand upon the
distilled language of the quality system requirements with practical
explanations and examples of design control principles. Armed with the
basic knowledge, manufacturers can and should seek out technology-specific
guidance on applying design controls to their particular situation.

Another design lifecycle guidance provided by FDA titled “Guidance for the
Content of Premarket Submissions for Software Contained in Medical Devices”
(FDA, 2005b) was initially published in May, 1998, and then later updated in May
2005. This guidance was concerned with both off-the-shelf and newly written
software, and was intended to identify the information needed by FDA for a
submission for marketing authorization to the agency, depending upon the risk
profile (denoted as “Level of Concern”) of the device. The guidance contained
requirements for various design documents generated throughout the design process
such as those addressing, illustrating or justifying: level of concern, software
description, device hazard analysis, software requirements specification, architecture
design chart, traceability analysis, software development environment description,
V&V documentation, revision level history and unresolved bugs or defects.

54
Also consulted extensively by the medical device industry is another
influential FDA guidance document titled “General Principles of Software
Validation” (Version 1.1, dated June 9, 1997), already introduced above. This
guidance document was revised in 2002 under the title “General Principles of
Software Validation; Final Guidance for Industry and FDA Staff” (FDA, 2002).
The scope of this guidance is much broader than might be suggested by the name,
i.e. software validation. It covers all phases of software life cycle management,
including planning, requirements-setting, design, construction or coding,
verification, testing at various levels and phases, software changes and maintenance,
traceability, and configuration management. Thus it essentially describes a cradle-
to-grave management system for software validation that might be a direct result or
indirect beneficiary of these different types of activity. This guidance reminds the
reader of the requirement in 21 CFR 820.70 (i) that validation is needed for “… any
software used to automate device design, testing, component acceptance,
manufacturing, labeling, packaging, distribution, complaint handling, or to automate
any other aspect of the quality system.” It also recommends an integration of
software life cycle management and risk management activities. It emphasizes that
the level of effort in software development should be proportional to the intended use
and the risk associated with the software.
A number of other guidance documents from the FDA address specific
aspects of software for particular purposes. These include guidance documents for
premarket notifications related to blood establishment software (FDA, 1997b), blood

55
establishment computer system validation in the user’s facility (FDA, 2007a),
computerized systems used in clinical trials (FDA, 1999c), computerized systems
used in clinical investigations (FDA, 2007b), the use of software in drug processing
(FDA, 1987), and computerized prescription recordkeeping (FDA, 1980). These
guidance documents are outside of the principal scope of the thesis research here, but
may provide additional information on FDA thinking with regard to software risk
management.
Software is of course important beyond the borders of the US and beyond the
medical device industry. Thus it is not surprising that several relevant standards and
guidance documents are found in the literature developed by certain national and
international standards-setting organizations. There is a clear tendency for
international standards to replace national standards with the passage of time. Like
guidance documents and unlike regulations, standards have the advantage that they
can be more easily revised in response to changing best practices.
An important body for the development of standards is the International
Organization for Standardization (ISO). ISO 13485:2003 (ISO, 2003) is a standard
for quality management systems for manufacturers. Certification to this standard is
widely sought by medical device companies doing business globally because several
international regulatory agencies, including those in EU and Canada, require
compliance to this standard if the product is to be commercialized in their
jurisdiction. Harmonized with FDA’s QSR design controls requirements, ISO 13485
also requires, under part 7.3, Design and development, the following design lifecycle

56
activities: Design and development planning, design and development inputs, design
and development outputs, design and development reviews, design and development
verification, design and development validation, and control of design and
development changes. Once again, no requirement of a particular software
development methodology is specified, as long as these activities and deliverables
are achieved.
In contrast, ISO/IEC 12207:2008 “Systems and software engineering –
Software life cycle processes” (ISO, 2008a) is a more specific process standard for
defining, controlling, and improving software life cycle processes. It:
...establishes a common framework for software life cycle processes, with
well-defined terminology, that can be referenced by the software industry. It
contains processes, activities, and tasks that are to be applied during the
acquisition of a software product or service and during the supply,
development, operation, maintenance and disposal of software products.

It is focused on software elements of a system and is harmonized with ISO/IEC
15288:2008 “Systems and software engineering – System life cycle processes” (ISO,
2008b) whose focus is on the system as a whole. Both standards can be used
concurrently on a single project or in a single organization, by using the different
elements of the two standards for consideration of software and other system
elements. Another joint ISO and IEC standard, ISO/IEC 15504, “Information
technology – Process assessment – Part 1-9” (ISO, 2003-11) is a 9-part standard
providing maturity models to assess the organization's capabilities for delivering
products such as software, systems and IT services, which was initially derived from
ISO 12207.

57
Choosing a Process Methodology
The regulations, guidance and standards discussed above emphasize the need
for staging risk management and design considerations in an orderly way, but they
do not give a particular methodology for such development. Nevertheless, a key step
in software development is the selection of a methodological framework to structure,
plan and control various development activities. How does a manufacturer choose
such a software methodology?
A linear or Waterfall model (or its variant V-model) has been traditionally
employed by the medical device industry. Figure 5 shows a typical Waterfall model
with various phases of software lifecycle, through the phases of pre-development,
development and post-development.

Investigation
& Planning
Requirements
Design
Construction
or Coding
V&V
Installation;
Operation &
Support
Maintenance
Retirement
Pre-development
Development
Post-development

Figure 5: Waterfall Model for Software Lifecycle Processes

58
Each phase has a specific scope and set of activities:
1. Pre-development: Activities focus on conceptualization, feasibility
studies and planning. Typically this phase begins with an expressed need
for a new or modified software product and a vision of how the idea can
be developed. Feasibility analysis related to technical, financial and
operational needs is performed. If the product is seen to be feasible,
planning activities and resource consolidation ensue. Consideration is
also given to software metrics to be used throughout the life cycle for
planning and project management purposes. An initial analysis of risks is
begun as a basis for subsequent risk management planning.
2. Development: Implementation proceeds with the goal of making a
working deliverable. Requirements are defined and use cases are
constructed; software design specifications and software architecture are
developed; construction or coding is carried out; and V&V/testing takes
place. These activities will typically be sequential. The development
phase will end with a comprehensive final review and release. In this
phase it becomes important to track software metrics in order to assess
various aspects of quality and performance and to predict future
performance. Planned risk management activities are important at this
stage because risks to safety and performance can be mitigated at lower
cost than would be the case if expensive repair activities were to be
needed after the product is released.

59
3. Post-development: Activities primarily involve installation, operation and
support, maintenance, and eventually retirement of the software. Most
time and resources are directed at software maintenance, typically driven
by active post-market surveillance of user satisfaction and adverse events.
It may include such activities as adding new functionality, resolving
defects, or responding to user complaints. A goal of work during the
earlier predevelopment and development phases is to reduce this effort.
Software teams must be vigilant not only to recognize problems in their
own software products but also problems in the products of competitors
that might presage incidents that could also be problematic for the whole
product class. The phase ends with retirement, often linked to the
introduction of next generation of a software product.

The Waterfall model has several strengths. It is easy to use and understand
even by inexperienced members of the software team. Planning and management of
resources are intuitive. It provides an orderly tracking system by mimicking the
design control process, and thus can be matched with it to ensure that quality,
reliability, maintainability and compliance objectives are met through objective
evidence, documentation, and reviews. However, it is easy to fall into the trap of
relying on the gated reviews to catch major issues, and leaving critical system
integration and testing near the end of projects, when serious design defects are more
difficult to correct (Doyle, 2010). Other weaknesses of the Waterfall method include

60
its lack of flexibility, slowness, relatively high costs, and significant requirements for
structural overhead, that restrict opportunities to iterate or respond to change in
requirements or design ideas. It also gives little opportunity for customers to
participate in the process until the end of the project (CMS, 2005).
The V-model is a variant of Waterfall methodology. It is popular among
medical device companies because it helps build traceability between requirements
and design elements with related verification and validation steps, in addition to
providing structure and ensuring transparent compliance to the development process.
Different levels of V&V or testing, for example, at the unit, integration and system
levels, shown in the right arm of “V”, are carried out at the corresponding levels of
development shown in the left arm of “V”, (Figure 6).

Figure 6: V Model for Software Lifecycle Processes (USDOT, 2007)

61
Waterfall type approaches have however been challenged by new
methodologies that have been recently introduced to the field. In part this has
occurred because software developers increasingly desire to replace the typical
passive and retrospective approach (e.g. what have been the problems in the field?)
with a proactive approach in which problems are estimated and anticipated (e.g. what
are the biggest risks to the user?) (Ru-Zhi, Pei-Yao, Ying, Le-Hong & Yun-Ting,
2005). Thus there is a strong interest in exploring other types of software
methodologies. However, adopting a new, untested methodology has risk especially
for safety-critical devices. Mallory (1993) suggests using pilot projects when
implementing new methodologies, to facilitate the learning process among software
team members. As experience is gained with the new methodologies, subsequent
new projects can be transitioned from an outdated methodology.
Another set of methodologies are various process improvement models, some
of which we have already discussed earlier in this section such as ISO 13485, FDA
QSR and ISO 15504. Further, Capability Maturity Model Integration (CMMI) is a
bench-marking methodology that was developed by members of industry,
government and the Carnegie Mellon Software Engineering Institute (SEI, 2011).
CMMI assesses the maturity of an organization’s software development process,
graded at 5 levels (Figure 7): Level 1 (Initial), Level 2 (Managed), Level 3
(Defined), Level 4 (Quantitatively Managed), and Level 5 (Optimizing). According
to SEI, CMMI is a process improvement approach that provides organizations with
the essential elements of effective processes, which will improve their performance.

62
CMMI-based process improvement includes identifying an organization’s process
strengths and weaknesses, and making process changes to turn weaknesses into
strengths (CMMI, 2011).

Figure 7: CMMI Maturity Levels (1-5) (CMMI, 2011)

Incremental methodology is a combination of linear (e.g. Waterfall) and
iterative development methodologies, in which a partial implementation of the total
system is initially constructed (i.e. highest priority requirements first), over which
additional functionality is incrementally/iteratively added, until full system design
functionality is completely implemented. In other words, a number of mini-
Waterfalls (one per iteration) are employed by breaking the project into smaller
segments (CMS, 2005). Likewise, the spiral development method combines linear
and iterative development methodologies focused on reducing project risk by
breaking a project into smaller segments as well as providing flexibility for change
during the development process (CMS, 2005).

63
Each cycle involves a progression through which the same sequence of steps,
for each portion of the product and for each of its levels of elaboration, from an
overall concept-of-operation document down to the coding of each individual
program (Boehm, 1996).
Each trip around the spiral traverses four basic quadrants with specific goals:
(1) To determine objectives including alternatives and constraints of the iteration, (2)
To identify and resolve risks, or evaluate alternatives, (3) To development and test
deliverables from the iteration, and (4) to plan the next iteration (Boehm, 1986), as
seen in Figure 8.

Figure 8: Spiral Model (Boehm, 1986)

64
A software development methodology that has sparked a widespread interest
among software development professionals in recent years is the Agile methodology,
a collection of methods based on iterative and incremental methodologies. Agile
Alliance, a non-profit organization to promote Agile development (Agile Alliance,
2011), described the evolution of this methodology as:
In the late 1990’s several methodologies began to get increasing public
attention. Each had a different combination of old ideas, new ideas, and
transmuted old ideas. But they all emphasized close collaboration between
the programmer team and business experts; face-to-face communication (as
more efficient than written documentation); frequent delivery of new
deployable business value; tight, self-organizing teams; and ways to craft the
code and the team such that the inevitable requirements churn was not a
crisis.

In order to understand the inherent difference between Agile and traditional
methods, it is important to appreciate the background and philosophy behind Agile.
Agile Alliance launched the Agile movement and wrote Agile Manifesto (Agile
Manifesto, 2001). The Agile Manifesto was developed to value certain items more
than the others, for example: 1) Individuals and interactions over processes and tools;
2) Working software over comprehensive documentation; 3) Customer collaboration
over contract negotiation; 4) Responding to change over following a plan.
There are several Agile methods such as Adaptive Software Development
(ASD), Feature Driven Development (FDD), Crystal Clear, Dynamic Software
Development Method (DSDM), Rapid Application Development (RAD), Extreme
Programming (XP) and Rational Unify Process (RUP), but one such method, called
Scrum, seems most popular. Scrum Alliance (Scrum Alliance, 2011), a not-for-

65
profit professional membership organization dedicated to increase awareness and
understanding of Scrum, describes Scrum methodology as follows (Figure 9).
A product owner creates a prioritized wish list called a product backlog.
During sprint planning, the team pulls a small chunk from the top of that
wishlist, a sprint backlog, and decides how to implement those pieces. The
team has a certain amount of time, a sprint, to complete its work - usually two
to four weeks - but meets each day to assess its progress (daily scrum).
Along the way, the ScrumMaster keeps the team focused on its goal. At the
end of the sprint, the work should be potentially shippable, as in ready to
hand to a customer, put on a store shelf, or show to a stakeholder.

The sprint ends with a sprint review and retrospective. As the next sprint
begins, the team chooses another chunk of the product backlog and begins
working again. The cycle repeats until enough items in the product backlog
have been completed, the budget is depleted, or a deadline arrives. Which of
these milestones marks the end of the work is entirely specific to the project.
No matter which impetus stops work, Scrum ensures that the most valuable
work has been completed when the project ends. (Scrum Alliance, 2011)

Figure 9: Scrum Methodology for Software Development (Scrum Alliance, 2011)

66
The illustration in Figure 10 captures the Scrum process with the addition of various
terminologies and roles important for its execution (Agile for All, 2011).

Figure 10: Details of Scrum Methodology (Agile for All, 2011)

Software Development and Lifecycle Management Tools
In addition to identifying the methodology for software development, it is
important to identify specific tools that can be used during the software life
cycle to create, debug or maintain software programs. These tools can
accelerate progress toward a final product and can also provide insight into
the status of the project by permitting the collection of quantitative data
related to quality, reliability, maintainability and performance of software
(Troisi, 1988).

The origins of software development tools can be recognized as early as the
1950s when the first computer systems were developed, but the types of tools and
their usage has evolved dramatically over the last few decades (Chappell, 2008a).
Most tools in 1970s were used for specific functions (Figure 11). For example, an

67
editorial tool would be used by the software developers to write code, while other,
different tools would be used in parallel, as separate functions, to compile, build
executables, test and manage new versions of the code. As time passed, these tools
were consolidated so that developers could perform a series of related activities more
efficiently. Editors and compilers were combined by early 1980s to form integrated
development environments (IDEs). These new tools were highly successful because
developers could fix the errors in real-time as code was written and compiled in the
same environment. Similarly, as team-based development became popular in 1990s,
the integration of other integrated tools, such as those to build, test and control
source code, not only became necessary but also delivered functionality that was not
possible when the tools were packaged as standalone tools.

Figure 11: The Evolution of Software Development Tools (Chappell, 2008a)

68
Further optimization of the software development process will require cradle-
to-grave tooling for a broader range of activities throughout software development
life cycle, including administrative functions such as program and project
management, requirements management, and configuration management, as well as
more traditional areas such as build management, test management, traceability
management and defect management, as shown in Figure 12 below.

Figure 12: Cradle-to-Grave Tooling of Software Development Lifecycle (Chappell,
2008a)

Future needs for tooling will also extend beyond the software development
lifecycle (SDLC), to application lifecycle management (ALM). ALM goes beyond

69
SDLC, extends well into the retirement or obsolescence of the software product
(Chappell, 2010), and can be divided into three distinct phases: Governance,
Development and Operations. The middle phase, Development, equates with SDLC
(Figure 13).

Figure 13: Application Lifecycle Management, ALM (Chappell, 2010)

In this model, governance extends over the entire span i.e. from the
conception of an idea through its subsequent iterations until the end of life (Figure
14). In contrast, the development phase is fragmented; it initially extends between
idea and deployment, and subsequently reappears at intervals as the product
undergoes various iterations for bug-fixes, upgrades, or the insertion of new
functionality. The operations phase, like governance, is more continuous but extends
between deployment and end of life, where effort is primarily expended on
maintaining the application.

70

Figure 14: Governance, Development and Operations Phases of ALM (Chappell,
2010)

71
Most business people understand the strategic value of differentiated business
processes. Yet the importance of ALM in supporting these processes gets
much less attention. In reality, any organization that creates custom software
should take the ALM process as seriously as it does any other critical
business process. ALM might be even more important, since it creates the
underpinning for the others…. Being better than your competitors at creating
and using custom software can bring substantial competitive advantage.
Similarly, being worse can put you at a significant disadvantage. If your
organization doesn’t see ALM as one of its most important processes, it’s
time to change that view. (Chappell, 2008b)

Overall, software development and ALM tools equip software professionals,
project managers, and other team members to pursue the challenging task of
developing a complex, high-risk yet safe medical device application, while at the
same time ensuring regulatory compliance as well as timely delivery of software to
the marketplace. Yet little has been written specifically on the tools that are used
most commonly by medical device companies. Thus, a knowledge of these tools
would assist in their application to improve the model that is envisioned in this
thesis. One of the goals of the research undertaken here is to identify which tools in
these areas are most used by software developers.
Conclusion of Literature Review
The literature review presented here is one component of the work package
needed to base the development of a model for risk management across the SLC.
The sparse literature that exists seems to suggest a system in evolution, where
software risk management is currently applied in a patchwork manner. The need for
a more systematic approach is especially critical for the medical device industry
where the consequences of undesirable device performance may be particularly

72
serious to patients. However, the literature identifying ways to develop a cradle-to-
grave framework for software risk management is poorly developed, and this
provides a strong motivation for further research and development of systematic
approaches. Since a framework must be built around a development methodology or
process, and must take into account the risk management practices and tools that are
most commonly employed (or may be commonly employed in future), a useful first
step is to examine which methodologies, risk management practices, and tools are
most commonly recognized by experts in the medical device field as “industry-
standard” or industry “best-practice”. From this analysis, we can propose a
systematic model for software risk management that will interface well with current
approaches used by the software industry.
Therefore, the goal of the this study is to explore effective software
development methodologies/processes, identify risk management best practices, and
compile various software development and lifecycle management tools to create an
integrated framework for SRM, using a combination of interviews and other
exploratory methods including literature presented in various fora. The study is
executed in the following sequence of steps (Table 1).

73
Table 1: Steps of Research

# Steps of research
1 Exploration of software development methodologies/processes, risk
management practices and software development and lifecycle management
tools in the industry at large (outside medical device industry).
2 Selection of software development methodology/process that shows most
promise, continuation of exploration of risk management practices, and
compilation of an inventory of various available software development &
lifecycle management tools.
3 Interview questionnaire development in three areas: (i) software development
methodologies/processes, (ii) risk management practices, and (iii) software
development & lifecycle management tools, with an emphasis towards their
usage in medical device industry.
4 Data Collection: Performing interviews as well as employing other exploratory
methods, such as reviewing literature presented in various forums or available
otherwise, to collect data in three areas of the study.
5 Data analysis, followed by the integration of selected
processes/methodologies, practices and tools to develop a SRM framework for
medical device industry.

74
CHAPTER 3
RESEARCH METHODOLOGY
Stage 1: Initial Exploration of Methodologies and Tools
As a first step in this research, the views of industry experts, users and
vendors were explored regarding trends in three areas of research: i) the use of new
versus traditional software development methodologies; ii) the most widely applied
risk management approaches and practices, and iii) the nature of tools currently used
to facilitate and automate software processes. The goal of this exploration was to
identify trends, with the intent to narrow the scope of study onto the most promising
methodologies, practices and tools in the software environment, for the purpose of
constructing a risk management life-cycle model. These three areas were explored
concurrently over the period of 3 months (March-May ‘10), starting with attendance
at Agile Leadership Forum (Appendix A), where methodology practitioners and
experts, as well as tool users and vendors were known to participate preferentially.
During these intensive events, it was possible to both hear presentations from
thought leaders and later obtain information through interviews. In this part of the
study, the interviews were generally informal, conversational, and semi-structured
(Patton, 2002). The information gathered from the presentations and interviews, as
well as the subsequent review of various publications, white papers, promotional
literature and other artifacts obtained from this forum, were used to refine the study
methods and interview questionnaire during stage 2. Several follow up phone calls
and emails were exchanged with the contacts established in the forum, and other

75
leads of potential participants for stage 2 were obtained in the process. This exercise
aligned the study scope with its desired objectives, and improved the content validity
of the interview and other qualitative methods for the next phase of the study.
In parallel, the information on the websites of tool vendors and online agile
discussion forums was also reviewed. This added to the information gathered from
face-to-face meetings, and provided an inventory of tools being used or developed
for use in the following software development activities:
a. Software Development Life Cycle (SDLC) tools: 1) Program and project
management; 2) Requirements management; 3) IDE: Integrated
Development Environment; 4) SCM: Software Configuration
Management; 5) Build management; 6) Code analysis; 7) V&V/test
management; 8) Defect management; 9) Post release: Customer support
and management; 10) Other tools.
b. Application Life Cycle (ALM) tools.
Because of so many types and categories of tools that existed, it was neither
the objective nor outcome of this study to gather a complete inventory of tools, but
rather to create a reasonable cross-section of options that might be candidates for
inclusion in the study’s main objective of creating a SRM framework. Starting with
stage 1 initial exploration and continuing well into stage 2 (discussed next), the study
continued to build the inventory and evaluation of tools based on the information
available at major fora widely attended by tool vendors, in the form of interviews,
presentations, leads/referrals, tool demos at vendor display booths, white papers

76
written by the tool vendors, experts or analysts, and information posted on the
websites of tool vendors.
Stage 2: Evaluation of Software Development Trends for Medical Devices
A second stage of the research involved structured interviews with key
opinion leaders working in or with medical device companies. The research was
conducted over the period of 13 months – starting with IQPC's 13th Annual Software
Design for Medical Devices conference in May ‘10 and ending with Better Software
Conference in June ‘11 (Appendix A). As in the initial stage, advantage was taken
of major symposia and other fora to listen to as well as meet with key opinion
leaders and practitioners who in many instances were presenting at the meeting. An
interview questionnaire tool composed of 10, 7 and 15 questions (Appendix B), was
constructed using a web-based design tool (Qualtrics, http://www.qualtrics.com/), to
guide interviews in the following three areas respectively: (i) new software
development methodologies/processes, (ii) risk management practices, and (iii)
software development and lifecycle management tools. The questions were
standardized, structured, and exploratory (Patton, 2002), and were deliberately made
open-ended to lead researcher and participants into an in-depth discussion that could
take the direction that the participant seemed to feel important.
The three areas of study had different numbers and types of participants
(Table 2). Most participants had expertise, interest or experience in only one aspect,
for example, methodology, risk management practices or tools, but some had a good
knowledge of more than one area of study. From these latter participants, it was

77
possible to gain insight into multiple areas at a single interview or seminar
presentation. The details of study participants are included in Appendix C.

Table 2: Participants and Data Sources of the Study

# Area of study Participant Description
# of participants/
data sources
1 Software
development
methodology/process
• Expert/Consultant
• User/Practitioner
• Regulator/Standards Body
• 3
rd
party/Independent Analysts
15-20
2 Risk management
best practices
• Expert/Consultant
• User/Practitioner
• Regulator/Standards Body
• 3
rd
party/Independent Analysts
10-15
3 Software
development and
lifecycle
management tools
• Supplier/Vendor
• User
• Regulator
• 3
rd
party/Independent Analysts
40-60
Total 65-95

Each interview session generally lasted about 30 minutes, and was typically
conducted in a quiet location that was convenient for the interviewee. When a
relevant presentation by a thought leader was given, answers to the interview
questions were extracted from information presented during that 45-60 min seminar.
Questions that were not covered explicitly in the presentation were asked during the
formal question and answer period after the presentation, or by soliciting further
input from the speaker through a shortened interview after the presentation. Each

78
presentation was considered to be a single source for purposes of participant
analysis. For the evaluation of tools, input from thought leaders was supplemented
by face-to-face interviews with experts at the display booths of tools vendors during
various symposia, by email or phone interviews, by inspection of vendor websites,
and by seminar presentations by tools users, regulators and independent analysts.
Responses from the participants were documented in long-hand notes, and where
possible, by backup electronic audio recording to facilitate later analysis. In
addition, document analysis was carried out on brochures and presentation material.
Occasionally, short interviews were conducted without note-taking during the
interview, but on these infrequent occasions, notes were made immediately
following the interaction.
Data Analysis and Development of Integrated SRM Framework
The third phase of the study involved the summation and integration of
research data. Results were grouped into the same three sections that are identified
above for ease of analysis, and in each section the findings of stage 1 and 2 of the
research were grouped, so that general trends could be compared to those in the
medical device industry. The output of the subsection that considered research
methodologies was a description of trends apparent from the interviews with regard
to current and future methodologies in the medical device field. The output of the
second subsection, that considered risk management practices, was a description of
most commonly used risk management practices in medical device companies. The
output of the third subsection, that considered tools, was the enumeration and

79
prioritization of useful tools at various stages of the SLC. Finally, the outputs of the
three subsections were used to guide a beginning model for a cradle-to-grave SRM
framework, developed in chapter 5. Construction of the framework involved the
integration of selected software development methodology, risk management best
practices, and tools.

80
CHAPTER 4
RESULTS
The study included a total of 90 data sources, sub-grouped below by
relevance to one of three main topics: (i) Software development Methodology/
Process, (ii) Risk Management Best Practices, and (iii) Software Development and
Lifecycle Management Tools. Appendix C contains details of study participants,
organizations and various data sources, in addition to their initials throughout this
chapter, wherever individual responses are presented.
Software Development “Methodology/Process”
This part of the study identified and explored the use of various software
development methodologies or processes in the medical device sector. This
information was used to guide the choices of an infrastructure for the risk
management framework that was the ultimate goal of the study. It was based on
information derived from 19 data sources or participants, 13 from inside medical
device industry and 6 from outside (see Appendix C-1). The sampled participants
included experts or consultants (m1=8), users or practitioners (m2=7), regulators and
standard bodies (m3=3), as well as third party or independent analysts (m4=1) of
software development methodologies or processes (Figure 15).
The views of these participants were solicited through interviews (7),
interactions at seminars or symposia (9), and information obtained from position
papers by experts or analysts (3). Appendix A contains a list of meetings where data
were collected and interviews were conducted.

81

Figure 15: Details of Study Participants: Software Development
Methodology/Process

Software Development Methodologies/Processes: Traditional vs. Agile
A starting point for the analysis was the comprehensive assessment of various
methodologies used by software developers. This was aided by referring to results
of a recent report by Forrester Research Inc. (Forrester, 2010b) that was identified
during an interview with the Forrester analyst (DW) who conducted this assessment.
This study identified the most common methodologies for software development to
be Agile (35%), Iterative (21%) and Waterfall (13%) methodologies (Figure 16).
The methodology/process nomenclature from this previous study was used in the
interviews of medical device software developers to understand more specifically
their preferences. Agile methodology’s popularity among software developers was
also confirmed by other study participants such as JB of Seilevel, and AH who was
0 2 4 6 8 10 12 14 16 18 20
Total Participants
Expert/Consultant (m1)
User/Practitioner (m2)
Regulator/Standards Body (m3)
3rd-party/Independent Analysts (m4)
Medical Device Software/Other

82
one of the seventeen founders of the Agile Alliance, which launched the Agile
Manifesto and the Agile movement.

Figure 16: Preferences in Software Methodology Amongst Users (Forrester, 2010c)

The Waterfall methodology was identified to be used most commonly in the
medical device industry. All medical device participants (N=13), including users or
practitioners (N=7), experts or consultants providing design controls services to the
industry (N=3), and regulators and standard bodies (N=3) confirmed that Waterfall
or v-model methodology has been traditionally most popular in their experience.

83
Reasons for this preference included the long history of experience with this method,
and its recognition and acceptance by regulators, who appreciated that its structure
allowed it to be integrated quite easily into design controls and other regulatory
requirements. V-model methodology was also observed to be popular among
medical device companies because it was particularly useful to build traceability
between requirements and design elements with needs for V&V, in addition to
providing structure and compliance to the development process.
In this study, a few participants (N=3) preferred CMMI methodology, and
these individuals were chosen for interview specifically to gain insight into the
usefulness of this methodology for software development. CMMI is a little different
from the other methods because it is principally a benchmarking rather than a
development methodology against which the maturity of an organization's product
development, acquisition and/or service-related processes can be measured on a scale
of 1-5. CMMI best practices tell an organization “what” to do, but not “how” or
“who” should do it. Study participants noted that a good CMMI rating has a
reputation for usefulness in demonstrating compliance in a regulated environment
such as aerospace, through a development process which requires high precision,
auditability and a framework of signoffs. One of the three (33%) CMMI
participants, MP of SEI, compared and aligned CMMI with medical device
regulations and standards such as FDA’s 21 CFR Part 820, ISO 13485, EU MDD,
IEC 62304, IEC 80002, IEC 60601-1, ISO 14971, FDA guidance on software
validation, OTS software, 510(k) etc, to demonstrate similarities between them in the

84
following areas: process requirements, requirements management, change control,
quality assurance, risk management, and verification & validation. The requirements
for training, written procedures and objective evidence in both environments were
also emphasized by MP. By this mapping exercise between CMMI and medical
device standards/regulations, MP concluded that CMMI covers all the requirements
of latter, while at the same time providing additional value in the process areas that
reduce risk for medical device companies. Two of the 3 CMMI experts/consultants,
HG of Entinex and PM of PEM Systems, discussed how they combined or related
CMMI practices with those of Agile. They reported the opportunity CMMI provided
for the software industry, while at the same time suggesting that Agile methodology
was the most popular software development methodology among developers in the
industry today.
Applications of Agile Method in Medical Device Industry
Agile methodologies were identified to be a less commonly used
methodology in medical device companies today, but they are experiencing rapid
uptake in companies with sophisticated software teams. AAMI representative LP,
one of the contributors in the study, noted that the goal of Agile is to eliminate the
risks associated with the traditional Waterfall methods in situations where processes
did not respond well to changing business needs or where the progress of software
abstraction was insufficiently visible. LP particularly noted useful Agile features
such as its focus on quality by ensuring correctness of product, customer needs via
product effectiveness through customer collaboration, productivity through improved

85
efficiency, speed and lower costs, and predictability through improved estimation
and planning.
LP further outlined Agile principles that AAMI viewed to be important and
applicable to the development of medical device software. These included, for
example: 1) Introduction of incremental and evolutionary changes across the
development life cycle with increments as short as a week, and evolution happening
as late as the last increment before a product is shipped; 2) Definition of what
“done” means, where “doneness” includes the requirements of the Quality
Management System that must be satisfied; 3) Importance of delivering customer
value through frequent customer interaction/validation regarding usability and safety
of the product; 4) Better ability to manage business and safety risk through team
collaboration to focus on a robust and safe design, and doneness criteria to ensure
items related to schedule and safety risk management are completed; 5) Process to
reflect at regular intervals and thus adapt the process to constantly improve quality
and efficiency of work.
Similar comments were made by MD of Edwards Lifesciences, in a white
paper (Edward Lifesciences, 2010) to which reference was made by another
participant. This paper suggested that Agile practices enhanced patient safety
compared to Waterfall methods. MD noted that the Waterfall method was built a
false premise that the requirements determined before the start of the development
process would be the best possible requirements, and would never change. Agile on

86
the other hand was constructed with a different philosophy that change should be
expected and encouraged as learning took place during product development.
MD also identified the following problems with Waterfall method which
were addressed better in Agile: 1) Large unprioritized feature sets: An accumulation
of unprioritized features or requirements precedes unprioritized development by
engineers when Waterfall methods are used; Agile does just the opposite, so that a
project running late will sacrifice low-priority/low-risk outstanding items that do not
affect patient safety; 2) Bloated architecture: The Waterfall practice to document a
detailed design at the beginning of a project can be used by senior engineers to lock
in their favorite styles, whereas Agile development favors a lean emergent
architecture; 3) Inability to accommodate inevitable change: Waterfall projects tend
to last longer, thus increasing the risk that the market needs may change during
development. Further, unanticipated change typically receives resistance from
engineers who build the architecture on the premise that the requirements have been
predetermined. Agile development factors in such changes by using architectures
and work strategies that can accommodate them; 4) Design misses: Many subtleties
in design cannot be captured at the beginning of a typical 1-2 yr project, so Waterfall
projects can lead to significant design misses. The Agile methodology addresses this
problem by delivering working code to the intended recipient at frequent intervals to
obtain feedback for next iteration.
Analysis of information, presented in a paper from GE Healthcare Imaging
Solutions unit, highlighted similar problems with the Waterfall process (GE

87
Healthcare, 2010). In that publication, AD and RH (GE Healthcare) stated that long
Waterfall project cycle times (12-24 months) encouraged feature creep beyond initial
requirements, as software teams avoided waiting until the next product development
cycle months away. The consequence of such feature creep was increased cycle
times of the present product release further. Customer feedback was sought late in
the project after requirements, design and coding was completed, at which time
complete changes to the design might be needed in order to incorporate customer
requests. They further noted that artificial barriers existed among various functions
especially marketing and engineering, whereas appropriate use of an Agile method
tended to increase interactions and reduce barriers.
Experience of Agile Methodology Among Medical Device Companies
The research of Forrester, previously seen in Figure 16, suggested that the
Agile methodology had become mainstream recently in the software development
industry in general. To understand if the medical device industry followed this trend,
all the medical device participants identified as users or practitioners of Agile
methodology (N=7) were interviewed specifically regarding their experience as they
evolved to, or considered an evolution to, Agile from traditional Waterfall
methodologies. Responses suggested that device companies adopted a hybrid model
rather than a pure Agile method to meet challenges of working in a highly regulated
environment, and to ensure all applicable regulatory requirements were fulfilled,
while at the same time realizing the potential benefits of Agile development method.

88
One example of a typical response was provided by AD and RH from GE
Healthcare’s Imaging Solutions unit, who described their adoption of Agile-based
Scrum in 2010 (GE Healthcare, 2010). Its introduction began cautiously with a
single 4 month pilot project in which a cross-functional team of executive leadership,
managers, marketers, developers, testers, and technical writers was trained in the
Scrum methodology and protected from outside distractions. As experience
increased, the Scrum methodology was rolled out to an entire site, and subsequently
to all development sites globally. Certain features that contributed to the success of
the implementation were described as follows: 1) The product owner was an integral
part of the development team; 2) Bi-weekly sprints were chosen, at the end of which
the product increments were completed. The customers could then be shown the
functionality, and their feedback could be solicited; 3) GE Healthcare’s joint
ventures, which had earlier used Agile methodology successfully, provided learning
experiences including opportunities to observe sprint reviews, to participate in
retrospectives and sprint planning, to discuss the value of frequent customer
feedback and to gain experience with the use of third-party tools like Rally's Agile
ALM platform. Additionally, training was provided by an outside Agile coach, who
offered customized Scrum training to the team members after a personalized
assessment of GE Healthcare’s products, organization, and development processes.
The respondents also felt that it was important to have senior leadership comfortable
with cultural change driven by passionate individuals working as change agents.

89
At the same time the need to operate in a highly regulated environment posed
challenges to the use of the new Agile/Scrum method. It required them to adopt a
hybrid development model that required more up-front planning and post-sprint
testing than a pure Agile environment, and significant customization to work within
the Quality Management System. They found it helpful for the ‘user stories’, i.e.
scenarios written in the business language of the user, to get scrutinized through a
number of additional quality and regulatory steps before acceptance by a diversity of
stakeholders, to ensure that all applicable regulatory requirements were fulfilled.
Likewise, several additional activities such as unit tests, code coverage, and code
reviews were added not only for regulatory compliance but also to add value to the
performance of the product.
St Jude Medical also implemented Agile using Scrum methodology, as
described by LM. The team did not attempt to use “out of the box” Scrum
methodology strictly. Instead modifications were introduced that included the
redefinition of the Product Owner as a collection of stakeholders including those
with different areas of focus such as clinical affairs, customer service, business, and
project management. The Project Manager was then designated as the spokesperson
for all stakeholders. A Scrum Master was designated as the team leader who
reported status to, and coordinated activities with, the Project Manager in order to
insulate the team from distractions. The team itself was sometimes bigger than
typical Scrum teams of 7 ± 2 members. Further some members were located across
multiple sites, and the Subject Matter Experts (SMEs) were shared with other

90
projects. Thus, Scrum was used as a project management framework, rather than an
implementation practice.
The St Jude’s experience with Scrum began recently and on a small scale,
with a project whose scope was to add a new functionality to an existing product.
Scrum was not being used for legacy products at the time of the interview. In each
sprint cycle, priority for testing concentrated on user stories that related to clinical
needs, and risks that were identified to deserve particular attention. Risks to the
project were considered as priorities as well. Other priorities included customer
requests, business needs and team dynamics. The higher priority features were
implemented in the earliest sprints, and were tested with greatest rigor by having re-
tests in each subsequent sprint thereafter.
The SJM process was stated to retain the 5 phases of a traditional Waterfall
methodology (planning, elaboration & construction, transition, production and
retirement), but the Scrum method was used in only the ‘Elaboration &
Construction” phase where most of the design and development work took place.
Each “sprint” was essentially a “mini-Waterfall”, at the end of which various
elements of documentation were baselined to ensure compliance with FDA
requirements. A comprehensive review was also held at the end of all sprints to
ensure compliance with FDA’s design review requirements.
The implementation of Agile by Bio-Rad Laboratories was discussed by WS
in depth in a slide presentation from which could be obtained illustrations as well as
verbal descriptions of the approach. It followed a hybrid approach much like that

91
described above, in which Agile methodology was used in an intermediate, design
and development phase of a Waterfall type process as shown in Figure 17. In this
intermediate phase, Agile iterations contained elements of the Waterfall model, such
as requirements, design, implementation, verification and validation. The respondent
expressed a firm belief that this modified approach ensured compliance to FDA
requirements while benefiting the development process. To facilitate its
implementation, the team ranked a list of customer requirements in order of priority,
and attempted to implement the most important set of requirements first. Agile
teams had cross-functional representation and were dedicated to one project at a
time.
The Bio-Rad approach was characterized by frequent, almost continuous,
demonstration of working software to users (Figure 18), a concept new to their
organization. Initially considered difficult to achieve, it was later identified as one of
the most useful contributions of Agile. At the end of most cycles, the developers
could actively interact with and provide demonstration of working software to the
marketing function, which served as a customer representation and provided
feedback to the developers to be incorporated in the next Agile iteration.

92

Figure 17: Hybrid Agile with Waterfall Elements at Bio-Rad Laboratories

Taken from Will Stubblebine, Bio-Rad Laboratories, presentation at Seminar: FDA & Industry
Leaders on Agile & Risk-Based Processes, Baltimore MD, 2011, with permission.

93

Figure 18: Inside an Agile Iteration at Bio-Rad Laboratories

Taken from Will Stubblebine, Bio-Rad Laboratories, presentation at Seminar: FDA & Industry
Leaders on Agile & Risk-Based Processes, Baltimore MD, 2011, with permission.

94
Working software was delivered at intervals of ≤ 3 months through “Interim”
releases (Figure 19) to certain types of clients, notably those in research laboratories
served by the Life Sciences division. These research use applications are subject to
less regulatory scrutiny than diagnostic instruments, so that more flexible options
with “interim” releases could be possible.

Figure 19: Agile Iterations at Bio-Rad Laboratories

Taken from Will Stubblebine, Bio-Rad Laboratories, presentation at Seminar: FDA & Industry
Leaders on Agile & Risk-Based Processes, Baltimore MD, 2011, with permission.

Other medical device, diagnostic and life sciences companies in the study
such as Life Technologies, Illumina, Gen-Probe and Varian Medical Systems were

95
also found to have been practicing hybrid versions of Agile method using much the
same approaches as those described above.
Regulatory Views on the Use of Agile Method in Medical Device Industry
The views of FDA and AAMI on the use of Agile method in the medical
device industry was obtained by attending a joint session developed by these two
organizations (Appendix A; Agile & RM), to present their views and to describe
initiatives to explore the use of the Agile method in the medical device industry.
Presentations and interviews there identified that an AAMI Medical Device Software
Standards Committee, Agile TIR (Technical Information Report) Task Group, had
been formed as a public-private partnership between the FDA and medical device
industry representatives in early 2010. The goal of the committee was to understand
how Agile methodology could be tailored for the regulated environment of medical
device industry. A TIR publication titled “Guidance on the use of Agile Practices in
the Development of Medical Device Software” was expected at the end of 2011 but
was not available at the time of this study. According to AAMI representative LP,
this guidance will introduce perspectives from regulatory agencies and Agile users
community, and contain four major sections: Aligning on Goals, Aligning on Values,
Aligning on Principles, and Aligning on Practices. LP mentioned that this TIR is
expected to align Agile practices with FDA’s QSR, General Principles of Software
Validation (GPSV) and IEC/ISO 62304, and include topics such as planning,
documentation, design reviews, product definition/requirements, software
architecture, detailed design, implementation and unit verification. Further, LP

96
identified that differing nomenclatures in the two environments presented challenges
for communication, and would be aligned. Examples were given where Agile terms
such as pair-programming, Test Driven Development (TDD) and user stories could
be matched with terms of the medical device industry such as design review,
verification and product definition respectively. LP concluded by saying that
emphasis in this work would be placed on ways to apply the Agile method within the
context of QMS, in order to manage business and safety risks, and produce
documentation with business value.
In the same interview and presentation session, JM from FDA also
encouraged the use of Agile in medical device industry as long as the compliance to
regulations was met. FDA had four active members including JM in this AAMI TIR
Task Group. JM made it clear that “FDA does not prohibit the use of Agile”. He
further stated that “FDA believes that Agile Methods can be tailored for use in
regulated environment”. Referring to GPSV (FDA, 2002) and its recommendation
on the integration of software life cycle management and risk management activities,
JM expressed a view favorable to the use of Agile for risk management throughout
lifecycle, and also stated, “In Agile, validation is thinly spread throughout life cycle
instead of at the end”. He felt that Agile method’s testing, reviewing, and sprinting
activities could be tailored to fulfill regulatory requirements. JM further noted that
FDA was particularly concerned about three specific elements of QSR that had a
direct impact on the use of Agile: (i) 21 CFR 820 Subpart C Design Controls, (ii) 21
CFR 820 Subpart J Corrective and Preventive Action, and (iii) 21 CFR 820 Subpart

97
M Records. JM identified that the new AAMI-Agile TIR would provide more detail
regarding FDA expectations, and its Appendix X would contain a list of important
regulatory requirements to which compliance must be assured.
Overall, JM’s views on Agile demonstrated FDA’s further involvement in the
application of this methodology in medical device industry since comments from
FDA’s RC a year earlier "If you can write code Agily, you can document Agily”.
RC had indicated that Agile method was potentially workable as long as design
documentation was also kept up-to-date, and implied FDA’s openness to the use of
newer methodologies as long as compliance to regulations were met.
Risk Management Best “Practices”
An extensive list of activities and approaches for risk management were
identified in Chapter 2. The goal of this part of study was to identify various risk
management “best practices” in medical device companies, and to evaluate
industry’s views on how these practices could be integrated into a risk management
framework. The fourteen participants (see Appendix C-2; Figure 20) who
participated in this part of the examination, were chosen to represent a spectrum of
perspectives from experts/consultants (p1=7), risk management users/practitioners
(p2=4), and individuals working with regulatory and standards setting bodies (p3=3).

98

Figure 20: Details of Study Participants: Risk Management Best Practices

Questions were asked both about formalized approaches to systematizing risk
management and about specific practices used to document or conduct risk
management activities. Results suggested that several methods were used by
different companies but the IEC 62304 standard for risk-based software
development, Human Factors Engineering (HFE) methods, development of
assurance cases, FMEA/FTA, and the design of corrective and preventive actions
based on post-market surveillance were viewed as important by most companies and
are discussed here.
IEC 62304:2006 Risk–based Software Development
The use of a risk-based approach based on IEC 62304:2006 Medical device
software – Software life cycle processes (IEC, 2006a) was identified by all study
participants having subject matter expertise in this area. Useful insights were gained
in particular from consultants who had an opportunity to compare the systems of
0 2 4 6 8 10 12 14 16
Total Participants
Expert/Consultant (p1)
User/Practitioner (p2)
Regulator/Standards Body (p3)
Medical Device Software/Other

99
several different device companies for whom they worked. Input from one such
individual, DO from Certified Compliance Solutions (CCS) Inc, highly
recommended IEC 62304 because it allowed development efforts to be scaled in
proportion to the safety classification of software (Classes A, B or C) suggested in
this standard. The participant noted that IEC62304 focuses on critical aspects of
design so that different levels of tests and reviews can be assigned to particular
elements. He further noted that its use has been increasingly emphasized by FDA
and ISO/IEC. The similarities between IEC 62304 and FDA guidance were further
illustrated in the participant’s formal presentation, whose key messages are compiled
in Table 3.

Table 3: Comparison of IEC 62304 and FDA Guidance

IEC 62304 FDA guidance
IEC 62304 section 5.1.1, page 31,
Note 1: The software model can
identify different activities for
different software items according
to the safety classification.
FDA General Principles of Software
Validation (FDA, 2002), page 7, section
3.1.2: The level of confidence, and therefore
the level of software validation, verification,
and testing effort needed, will vary depending
on the safety risk (hazard) posed by the
automated functions of the device.
IEC 62304 classifies software
system or item according to
possible hazards as Class A, B or
C (discussed above)
FDA Reviewer Guidance (FDA, 2005b)
classifies software as Minor, Moderate or
Major LOC (Level of Concern) based on the
hazard.

100
Input from TC of Covidien reinforced the usefulness of an IEC 62304 risk-
based approach in their organization. It guided them in prioritizing resource
allocation so that class-A software received less rigorous evaluation than class-B and
class-C software items. For example, activities related to risk management, software
architecture and component tests were only performed on Class B and C software
items, and initialization of variables as software verification acceptance criteria was
required only for Class C software items. Furthermore, a software system or item
could inherit its parent class or be given a new class, as justified by a rationale
(Figure 21).

Figure 21: Assigning IEC 62304 Safety Classes to Software Items at Covidien

Taken from Thuy Cook, Covidien, presentation at IQPC - 14th Annual Software Design for Medical
Devices Conference, San Diego, CA, 2011, with permission.

101
Human Factors Engineering (HFE)
Human factors engineering was explored with fewer participants, but
particularly one participant, EI from Abbott, had a deep experience and subject
matter expertise in this area. During the interview, EI drew attention to the growing
use of HFE to enhance medical device safety. HFE was described as the application
of behavioral science to the design and evaluation of systems and devices through
ergonomics, usability engineering, user experience and user centered design. EI
characterized “use errors” to be repetitive, predictable, and identifiable readily
through usability engineering and hazard analysis, which can be minimized by
appropriate changes in design. Material provided in EI’s presentation was able to
guide the identification of key trends and recent publications by AAMI (AAMI,
2009), including details of a useful HFE process (Figure 22), and various human
factor activities throughout the design process that were thought to fulfill current
requirements of FDA and other international regulators (Figure 23).

102

Figure 22: Human Factors Engineering Process (AAMI, 2009)

103

Figure 23: Human Factor Activities During Design Controls (AAMI, 2009)

Use of Assurance Cases
An emerging approach that was recognized in a seminar
presentation/interview was the use of assurance cases to systematize risk
management. CW from the Software Engineering Institute (SEI), was part of an
FDA-private sector team which developed the concept of assurance cases for
medical device safety. CW describes an assurance case as containing a claim, along
with its auxiliary evidence, that a system is acceptably safe, secure, and reliable in a
given context. It links the claim to the evidence with a supporting argument as seen
in Figure 24.

104

Figure 24: Assurance Cases for Medical Devices as Described by SEI

Taken from Charles Weinstock, Carnegie Melon Software Engineering Institute (SEI), presentation at
Seminar: FDA & Industry Leaders on Agile & Risk-Based Processes, Baltimore MD, 2011, with
permission.

CW identified that the emerging importance of this approach is reflected in a
new standard, ISO/IEC 15026-2:2011Systems and software engineering - Systems
and software assurance - Part 2: Assurance case (ISO, 2011), that was released at the
time the interviews were conducted, and was also then examined as part of the
research. According to CW, assurance cases augment testing where traditional
testing by itself is inadequate or too costly. They are used extensively in developing

105
safety-critical systems in Europe, and are generating increasing interest in the US.
He believes that the FDA wishes to go beyond hazard analysis and test results to
assure adequate mitigation of hazards, and this has been reflected in the new FDA
guidance “Guidance for Industry and FDA Staff - Total Product Life Cycle: Infusion
Pump - Premarket Notification [510(k)] Submissions” (FDA, 2010d), in which FDA
is suggesting the use of assurance cases. This specific call for assurance cases may
eventually apply to all devices containing software. According to another
participant, RC from FDA, the FDA would like to see 510(k) and other submissions
organized by assurance cases, as suggested in this draft guidance. He noted that
even new infusion pump 510(k) applications that had been submitted prior to the
publication of the guidance and had almost completed their review/approval process
were sent back by FDA to the manufacturers with instructions to meet this new
guidance. In the view of FDA, these companies invariably argued unsuccessfully
that the information presented in their application was sufficient. In the judgment of
FDA many of these submissions still had issues ranging from poor documentation of
requirements, to inadequate hazard analysis and poor human factors considerations.
Use cases are not the perfect solution to risk management, however. CW
noted that assurance case often relies on subjective criteria for evaluation.
Additionally, more data often could be needed to identify subtle defects, and
companies and regulators were not always sufficiently experienced in knowing how
to make sound reliability arguments. Nevertheless, participants in this part of the
study seemed to believe that assurance case patterns hold promise of capturing valid

106
arguments, guiding reliability improvement efforts, and providing a basis for
discussion among engineers, and between developers and assessors.
FMEA/FTA
The two most common specific risk analysis tools discussed by participants
were FMEA and FTA. The inductive, bottom-up approach of FMEA was considered
complimentary to the top-down, deductive approach of FTA. When conducting
FMEA, most companies were found to use a conventional tabular format for risk
analysis. One such system, illustrated by TC of Covidien, seems typical. It uses a
table to identify various failure modes in their devices, and prioritizes those failure
modes by the severity and likelihood (Figure 25). The cause of failures are
controlled or mitigated through risk control measures to improve the safety profile of
devices, and these actions are then documented in the same table.

Figure 25: FMEA (Covidien)

Taken from Thuy Cook, Covidien, presentation at IQPC - 14th Annual Software Design for Medical
Devices Conference, San Diego, CA, 2011, with permission.

107
The alternative, FTA, uses Boolean logic to combine a series of lower-level
events (i.e. possible causes) leading to the failure (top-level event). A typical
approach used by EI of Abbott (Figure 26) also suggested that companies are
implementing the method conventionally following the guidance in IEC 61025 -
Fault Tree Analysis (IEC, 2006b).

Figure 26: FTA as Discussed by EI, Abbott

Taken from Edmond W. Israelski, Abbott, presentation at Seminar: FDA & Industry Leaders on Agile
& Risk-Based Processes, Baltimore MD, 2011, with permission.

108
Use of V&V Activities
V &V testing was identified by all participants as key to software risk
management throughout SDLC. HL from Given Imaging indicated several software
quality assurance (SQA) processes and controls implemented within their
organization to improve risk-profiles of their medical devices (Figure 27).

Figure 27: Software Quality Assurance (SQA) at Given Imaging

Taken from Hagai Livni, Given Imaging, presentation at IQPC - 14th Annual Software Design for
Medical Devices Conference, San Diego, CA, 2011, with permission.

HL expanded on SQA processes and controls by describing four levels of
testing, including unit, component, integration and system testing and the use of
automation within each level. Further, the HL’s company was described to use static
verification at the document level, where software was not run but specifications
were checked against product definitions and risk analysis, and test plans were

109
checked against specifications and risk analysis. It then performed software level
verification by performing code reviews with static code analysis tools, and dynamic
verification by carrying out white and black box testing. Great emphasis was placed
on clinical validations, clinical trials, and risk assessment based on abnormalities
found during system level validation tests.
Automation was exercised at all test levels by Given Imaging to expose
defects in the unit level at early stages. The testing cycle durations were reduced by
running nightly test runs, so that testers could spend more time on manual testing of
more complex scenarios. Automated unit tests in two modes, GUI Runner and
Console Runner using Nunit tool, were created by the developers after they had
implemented their code. Similarly, automation was conducted at the component
level through white box testing of core engines of the application i.e. video
construction and video player, on nightly builds to ensure that no problem was
introduced since the previous execution. System test automation was executed using
the KDT (Keyword Driven Testing) tool which runs a dedicated engine within the
QTP (Quick Test Professional) that calls other QTP functions. The measurement of
software quality is assessed quantitatively at Given Imaging using the number of
defects found at various stages of SLC as a metric. The goal was expressed as one of
“finding as many defects as possible, as early as possible”. This measurement was
felt to provide a good measure of assurance and software product maturity. It also
helped to gauge the effectiveness and completeness of software V&V. Measures
such as defect density i.e. the ratio of number of defects per program’s lines of code,

110
were identified to help in determining areas where greater focus is needed, while
defects’ trend monitored the maturity level of different areas such as defects closing
rate, high severity defect density and regression defect percentage. Additionally, the
following formula could be applied for every phase of SLC (i.e. requirement, design,
implementation, verification, production) to assess the effectiveness of SQA
activities.
SQA effectiveness = n1/(n1 + n2)
where
n1 = number of defects reported by SQA during testing in a given phase (or
before product release) and accepted; and
n2 = number of defects reported in the next phase (or after product release).
The higher the percentage in earlier stages, the more effective the SQA process was
judged to be.
Similar observations were also made in interviews with LM from St. Jude
Medical, who stated that their software development teams considered unit tests and
static analysis as very important software verification activities. They automated
such activities as well, but using a tool (Coverity) to ensure that the code was
constantly evaluated during development. Similarly, WS from Bio-Rad Laboratories
identified that they fully automated low level unit tests and heavily automated
acceptance tests, which they identified as one of the most useful and complementary
V&V activities, along with the use of newly instituted Agile software development
methodology at the organization. as described earlier.

111
Post-development Risk Management Activities
Post-marketing risk management is largely driven by product changes, or by
adverse or new findings in the field, and thus may have a substantial linkage to
regulatory requirements and FDA involvement not so typical for other/earlier stages.
The current views of US regulators with regard to post-marketing risk management
were summarized in a presentation by FDA’s Larry Spears in one of the seminars
(see Appendix A; Agile & RM), in which he emphasized that device manufacturers
were expected to use post-market events such as complaints, adverse events captured
in Medical Device Reports (MDRs), recalls and corrections, to initiate root cause
investigation and resolution through a corrective and preventive action (CAPA)
framework. The discussion reinforced current thinking in the software risk
management field that risk management extends beyond software development into
later phases of software maintenance. In line with FDA expectations, TH from GE
Healthcare reported that their risk management system was implemented using a
matrix that linked all known hazards detected at any time in the product life cycle to
the hazardous situations with which they might be associated. These are then
assessed, mitigated, controlled and monitored throughout the remaining SLC until
the product is retired.
Software Development and Lifecycle Management “Tools”
The third stage of interviews and artifact analysis was conducted to examine
which development and lifecycle management tools are currently in use or predicted
to be important for facilitating software improvement and risk management during

112
the life cycle of the product. The large numbers of participants (n=57) that were
available for this part of the study, reflected in part the proliferation of vendor
companies providing these specialized tools (Figure 28), and included tool suppliers
or vendors (t1=45), users (t2=5), regulators (t3=1), and third party or independent
analysts (t4=6). The views of participants were solicited through interviews (14),
participation in seminars or symposia where tools were discussed (7), and inspection
of information obtained from position papers written by the tool vendors, experts or
analysts, or from information posted on the websites of tool vendors (36). Appendix
A contains a list of meetings where most of the presentations and interviews of study
participants occurred, and Appendix C-3 includes the details of
participants/organizations contributing to this study. Most of those interviewed were
not specifically focused on the medical device sector because the use of the tools cut
across software design in a variety of sectors.

Figure 28: Details of Study Participants: Software Development and ALM Tools

0 10 20 30 40 50 60
Total Participants
Supplier/Vendor (t1)
User (t2)
Regulator (t3)
3rd-party/Independent Analysts (t4)
Medical Device Software/Other

113
Results of this work yielded a very large number and diversity of tools. Most
tool categories had alternative solutions provided by multiple competing vendors.
Results also seemed to indicate that the tools market was in a state of transition.
Several vendors are competing with products of different breadth and price to serve
an industry yet to mature in terms of its adoption of these tools especially for end-to-
end tool automation of SLC processes.
SDLC and ALM Tools
The study focused on two principal types of tools including tools for specific
activities during the SDLC, and tools designed to manage the life cycle as a whole
i.e. Application Lifecycle Management (ALM) tools. ALM tools provide the ability
to link business management to software engineering, through integration with
various individual abilities of SDLC tools. SDLC tools evaluated in this study were
those associated with different phases of the lifecycle outlined in chapter 2.
Predevelopment tools that were evaluated were those that simplified the beginning of
program and project management. Development tools were numerous and included
tools that contributed to the management of management of requirements,
configuration, and builds, and analysis of code. It also included tools that assisted
with development i.e. Integrated Development Environment (IDE) tools, and those
which allowed V&V/test and defect management. Post-development tools were
those directed at installation, operation, maintenance or retirement of the software,
such as customer support and management tools.

114
1. Program and project management tools.
These tools provide a framework to manage the scope, duration, cost, quality,
communication needs and risk of projects. Tools most often discussed in this
domain originated both from large vendors such as Microsoft (MSProject), and small
vendors such as QSM and Hansoft (Table 8). In addition to these stand-alone tools,
other tools include program and program management features contained as a part of
more extensive software suites directed towards comprehensive ALM. Such products
included those from vendors such as Rally, MKS, Parasoft, VersionOne and
Microsoft (TFS). The representatives of all the vendors mentioned here were
interviewed at the forums, and the demonstrations of their tools viewed at the display
booths.
2. Requirements management tools.
Requirements management tools are used to define, prioritize, and maintain
requirements for software systems and applications. They are also used to trace
requirements to test cases in order to ensure that all requirements are met and
implemented in the design. A very large number of tools were found to reside in this
domain, and the analyses of certain third-party, independent analysts and consultants
with expertise in this type of software development tooling were used to guide the
identification of the most common and most useful tools. The participants further
identified sources of comparative evaluations published to guide tool selection. For
example, a participant JB from Seilevel drew attention to their systematic evaluation
of tool vendors in the requirement management domain, which used quantitative

115
scores to rank vendors on their tool’s ability to provide various features, as shown in
Table 4 (Seilevel, 2011).

Table 4: Requirements Management Tool Evaluation (Seilevel, 2011)

Tool Analysis
Ease of
Use Modeling
Requirements
Architecture
Review &
Collaboration Writing
Caliber 1140 566 1053 502 650 1260
MKS (ALM) 1104 634 416 544 870 1224
Qpack 1072 618 299 530 770 1224
3SL Cradle 1244 568 780 502 760 1224
Polarion 1132 588 546 530 815 1188
IBM Rational
DOORS
1124 612 481 528 785 1188
inteGREAT 1264 664 1092 528 855 1176
Blueprint 1160 636 1092 498 840 1152
Kovair ALM 1228 616 351 550 795 1152
Contour 1000 558 221 496 795 1152
IBM Rational
Composer
1164 574 819 546 735 1152
HP ALM 1088 542 299 466 600 1152
TopTeam Analyst 1168 646 1079 518 775 1128
Siemens Teamcenter 984 610 520 482 710 996
Enterprise Architect 1012 500 845 466 575 984
TraceCloud 888 520 481 498 735 960
Microsoft TFS
(ALM)
832 434 364 458 510 840

116
Requirements management tools were also evaluated by High Rely, a
software consulting, development and certification firm. These results were reported
in a document (Krasner, 2010) that listed a number of tools as shown in Table 5.
High Rely concluded that only one of 7 tools in their study, the DOORS
requirements management tool, met their “Fully Provided” assessment for all listed
categories.

Table 5: Requirements Management Tool Evaluation (Krasner, 2010; High Rely,
Inc.)

Tools: CRM = Caliber RM; IBMR = IBM Rational Pro; RaQ = RaQuest 2.4; Cont = Contour; DCSE
= Dassault CSE; DOOR = IBM Rational DOORS; Rely = RelyTRACE

3. IDE (Integrated Development Environment) tools.
IDE is a software development environment in which developers write and
compile code, as well as fix its errors in real-time. Forrester Research Inc provided a
useful assessment of common tools for integrated development (Figure 29) at one of

117
the meetings attended during the study. Of these tools, two stood out the most in
terms of popular use among software developers: Visual Studio from Microsoft and
Eclipse.

Figure 29: Popular IDE Tools (Forrester, 2010a)

4. SCM (Software Configuration Management) tools.
SCM tools are used for revision control, source control or source code
management to enable software developers and managers to manage multiple
versions because of ongoing software builds, changes, defect fixes etc, as well as
branching and merging of source code. One study participant pointed to a recent
evaluation of these tools (Table 6), published by a consultancy firm practicing in
medical device industry, Embedded Market Forecasters (Krasner, 2010).

118

Table 6: SCM Tool Evaluation (Krasner, 2010; High Rely, Inc.)

SCM tools Evaluation
SVN – Subversion Best choice for small companies
AllChange – Intrasoft Flexible and customizable
CM Synergy – IBM
Rational/Telelogic
One of the best choices for medium to large size
projects
ClearCase – IBM Rational One of the most popular choices for medium to large
size projects
Perforce Not as powerful as ClearCase for the price
PVCS – Merant Offers basic support for configuration management
Razor – Visible Systems Need attaching shell scripts both before and after
Razor events
Visual SourceSafe –
Microsoft
Offers basic support for configuration management
RCS Pro-Component SW Offers basic support for configuration management

119
Forrester (Forrester, 2008), also gathered the preferences regarding SCM
tools in the software development industry in Figure 30.

Figure 30: SCM Tool Usage Amongst Software Developers (Forrester, 2008)

5. Build management tools.
These tools provide solutions to automate the software “build” process i.e.
the process of conversion of source code into binaries. Both commercial and open
source solutions are available to perform automated build and workflow processing.

120
This study explored online resources and other leads obtained during the study from
other participants, to compile a list of tools in this domain from vendors such as
cruisecontrol Hudson, urbancode Anthillpro, Apache Ant and electricloud (Table 8).
6. Code analysis tools.
Tools for code analysis include static analysis and functional verification
tools, as well as structural coverage tests. These activities essentially fall under
software “verification”, and are made possible because of tools. High Rely’s
evaluation of these tools (Krasner, 2010) is included in Table 7. Others identified by
EMF included products from Coverity, Gramma Tech, IPL, Klockwork, LDRA,
Parasoft, PC-Lint, Polyspace (The Mathworks), Programming Research,
RationalTest RealTime, IBM/Telelogic Test Conductor/ATG, and Vector Software.

Table 7: Code Analysis Tool Evaluation (Krasner, 2010; High Rely, Inc.)

Code analysis tools Evaluation
VectorCast Avionic specific
GCover Green hills integrated path coverage
IPL Traditional coverage
Telelogic CodeTest Traditional coverage
LDRA Modern analysis, strong in Ada
RationalTest RealTime Full suite, structural coverage
Coverity Prevent SQS Resolve critical defects in C, C++ and Java
PolySpace Verify C, C++ and Ada

121
7. V&V/Test management tools.
Attention was drawn by one participant to research findings of Voke
Research, which compared tools for V&V or testing (Voke, 2010). Voke assessed a
number of vendors, including Coverity, Electric Cloud, Fanfare, HP, IBM/Rational,
Klocwork, Micro Focus, Microsoft, MKS, Original Software, QMetry, Replay, and
TOMOS, and compiled their analysis as shown in Figure 31. Tools from Microsoft,
Coverity, Replay and HP emerged as leaders in this assessment, followed by IBM,
Electric Cloud, TOMOS and QMetry.

Figure 31: Leaders in Testing Platform Tools (Voke, 2010)

122
8. Defect management tools.
Defect management tools are designed to track errors and code problems, and
thus provide a closed-loop process between requirements, implementation and
V&V/testing. This study explored and compiled a list of tools in this domain from
vendors such as Bugzilla, JIRA, FitNesse and IBM Rational ClearQuest (Table 8).
9. Customer support and management tools.
Customer support and management tools help to capture, track and manage
various customer issues as a consequence of software performance in the field.
These tools usually interface with other tools internal to the organization, such as
CAPA, complaint handling, and defect management systems, so that the software
defects can then be resolved. This study found that various organizations use a
home-grown database for this management, while others use off-the-shelf tools such
as salesforce.com (Table 8).
10. Other SDLC tools.
Several other types of SDLC tools exist for miscellaneous purposes during
software development. Some of these tools were found in this study from dynaTrace
and Replay Solutions and S2 Technologies (Table 8). A debugging tool from
dynaTrace combines code-level diagnostics with an end-to-end transaction view of
how an application behaves under load, to identify root-causes of various issues with
the software application’s behavior. Another diagnostic tool from Replay Solutions
functions like a DVR (Digital Video Recorder) for TV (Tele-Vision), uses recording
and replay technology, combined with real time execution analytics to communicate,

123
recreate and fix run-time software program defects. This software debugging tool
records all inputs and events affecting an application server while it is running, then
replays those inputs with the original binaries to create a live program environment
to reproduce a defect, so that developers can investigate its root-cause. Further, S2
Technologies offer a combination of consulting services and testing tool technology
in defect reduction and test automation.
11. ALM (Application Lifecycle Management).
As indicated in the beginning of this section, while individual tools (e.g. test
management or IDE) pertain to individual activities/phases in SDLC, ALM tools
pertain to the “methodology/process” of software development (e.g. Agile/Scrum,
Waterfall, or hybrid). Forrester Research assessed leaders in ALM domain in a
publication (Forrester, 2010b), obtained from DW of Forrester who was a key
contributor to the assessment. Large vendors such as Microsoft, IBM and HP, as
well as others e.g. Rally Software, CollabNet, Atlassian, MKS and VersionOne
emerged as strong performers and leaders in ALM tooling in this assessment.
Use of ALM and SDLC Tools Among Medical Device Companies
Results of the interviews suggested that ALM and SDLC tools were being
used increasingly in medical device software, and for much the same reasons and
purposes as in other industries. One medical device participant, DJ from Covidien,
found these tools useful throughout many activities, including (with the particular
tool that they used in parentheses) tools for requirements management (IBM Rational
RequisitePro), test management (IBM Rational Quality Manager), and change

124
management (IBM Team Concert). Covidien stated that they were using these tools
not only to automate and thus improve its efficiency of the software development
process, but also to ensure compliance through documentation by linking these
SDLC tools with other elements of quality/documentation management system (e.g.
for Design History Files) as seen in Figure 32. Covidien is also able to reuse
requirements and tests across various product lines and generations because of these
tools.

Figure 32: Use of SDLC Tools at Covidien

Taken from David James, Covidien, presentation at IQPC - 14th Annual Software Design for Medical
Devices Conference, San Diego, CA, 2011, with permission.

125
Furthermore, AD and RH from GE Healthcare’s Imaging Solutions reported
that their unit was using Rally's Agile ALM platform for useful insight into cross-
team dependencies and real-time status updates with their recently implemented
Agile software development methodology (GE Healthcare, 2010). With these
capabilities, Agile/Scrum teams could exchange user stories and tasks, so that teams
that completed their own tasks early were able to help slower ones. Similarly, WS of
Bio-Rad laboratories also reported using Rally's Agile ALM platform with the newly
instituted Agile methodology. Other medical device and biotechnology participants,
including Varian Medical Systems and Illumina, reported the use of ALM tools from
MKS and Microsoft (TFS) respectively for their software development projects.
A few tool vendors in ALM domain, e.g. Parasoft (Parasoft, 2011) and MKS
(MKS, 2011), have written white papers exclusively for the medical device industry,
to explain how their tools ensure compliance with FDA and other regulatory
requirements. Representatives of both vendors – MJ from Parasoft and JL from
MKS - were interviewed and tools of both companies were assessed to gain further
insight into their claims of meeting the requirements of the device industry.
According to Parasoft: “For medical device software development—Parasoft
Concerto provides a pre-configured system with processes and best practices that
assist organizations to meet FDA guidelines and medical device industry standards
for software development”. Parasoft’s Concerto ALM tool (Figure 33) provides a
suite of functions, including tools for process/project management, requirements
traceability, real-time visibility, correlation of tests/requirements/code/builds/project

126
tasks, and integration of V&V activities ( peer code reviews, static analysis, unit
testing, manual testing and regression testing) throughout the SDLC. Parasoft says
that its tool offers built-in configurable templates for FDA compliance, and overall it
“supports the FDA’s vision of an integrated SDLC for C, C++, Java, and .NET with
Parasoft Concerto for Medical Device Software Development”.

Figure 33: Parasoft’s ALM Tool (Concerto) for Medical Device Industry (Parasoft,
2011)

MKS also serves needs of medical device industry by identifying their
specialized challenges, and providing solutions through their ALM solution called

127
Integrity (Figure 34): “Manual effort required to comply to ISO and IEC standards
as well as FDA and CE Mark Regulatory Requirements is time consuming, error
prone and costly”. The Integrity solution for medical device engineering companies
demonstrates compliance in minutes with automated report generation rather than the
weeks required with manual processes”. An MKS publication emphasizes how their
ALM tool is able to manage various systems and software development processes, to
provide accurate real-time visibility into the progress of the project, and to connect
risk management activities with requirements, code and tests.

Figure 34: MKS’s ALM Tool (Integrity) for Medical Device Industry (MKS, 2011)

128
One particular feature of such tools that was emphasized by all of the
interviewed participants was the need for validation of electronic signatures (e.g.
approvals) and records in compliance with FDA’s Part 11 requirements (FDA,
2003).
FDA’s View on the Use of SDLC Tools in Medical Device Industry
FDA’s views regarding the use of SDLC tools by the medical device industry
could be studied at IQPC's 13th Annual Software Design for Medical Devices
conference (Appendix A). Participant RC from FDA specifically mentioned static
analysis code tools as important, as reflected in the following comments: “If you use
static analysis tools you are ahead of the game”, “Recommend you use it nightly and
correct as you go”, and “Key is to start early so it does not grow out of hand”.
RC also mentioned that FDA was using three specific static analysis tools,
Code Sonar, Poly Space by Mathworks, and Klocworks, and that FDA planned to
process all code from medical device manufacturers through their tools, unless there
was a documented evidence that manufacturers had already used the tool and had
provided the output to FDA. According to RC, a manufacturer would be asked to
explain every finding of the tool if FDA ran the code themselves. However, if a
manufacturer ran the static analysis and overrode certain exceptions, documentation
of their appropriate justifications in configuration documentation would be accepted
by FDA. RC concluded by saying that FDA often could attribute major issues in the
field to the software in medical devices. Thus it was putting strong emphasis on the

129
proof of “100%” code coverage by the manufacturer through manual code reviews
supplemented by static analysis.
Inventory of Tools
In addition to the tools discussed in this section so far, this study searched
other tools on vendor’s websites or at display booths in conferences to create the
compilation shown in Table 8.

130
Table 8: Inventory of SDLC and ALM Tools

Tools SDLC/other activities Tool name/vendor Comments
ALM
Application Lifecycle
Management
Rally Parasoft MKS VersionOne MS TFS
ThoughtWorks Studios TechExcel Collabnet IBM HP
Software Development Life Cycle
Project & program
mgmt.
MS Project QSM Hansoft
Requirements
management
IBM Rational
RequisitePro
IBM Rational
DOORS
See Table 4 and Table 5 for
others
IDE Oracle JDeveloper MS Visual
Studio
Eclipse See Figure 29 for others
SCM IBM Rational
ClearCase
Subversion AccuRev Perforce Microsoft
VSS
See Table 6 and Figure 30
for others
Build management cruisecontrol Hudson urbancode
Anthillpro
Apache Ant electricloud
Code analysis Klocwork Code Sonar LDRA Mathworks
Poly Space
See Table 7 for others
V&V/Test
management
IBM Rational Quality
Manager
HP Quality
Center
MS Test
Manager
See Figure 31 for others
Defect management IBM Rational
ClearQuest
Bugzilla JIRA FitNesse
Other
Customer
Support/Mgmt
Salesforce.com Interfaces with QMS
systems (Complaint
handling and CAPA), and
defect management tools
Other S2 Technologies dynaTrace Replay
Solutions

131
CHAPTER 5
DISCUSSION
A core requirement for medical product software is management of risk, yet
the current approaches to software risk management are typically fractionated and
incomplete across the product lifecycle. The goal of the research presented here was
to derive a sufficient understanding of current and emerging software methodologies,
risk management best practices and tools that a realistic and useful model for
integrated risk management could be built to encompass the SLC. Without such a
background, a risk management model might be developed that is outdated or poorly
conceived because it does not take into account the current approaches in the medical
device industry today.
Consideration of Methods
This exploratory research used qualitative methods, including attendance at
presentations, artifact analysis and the conduct of in-depth interviews to acquire
information to base the model that will be presented in this chapter. Such methods
were believed to be more effective for an early-stage study that had a little precedent
in the literature. The intent of the research, to capture opinions, ideas and trends,
would be difficult to achieve with quantitative methods like surveys, which rely on a
reasonable knowledge of current practices and a good understanding of the
participant population to construct an appropriate survey tool. Interviews and
artifact analysis have particular strengths for exploratory studies. When time can be
spent with a participant in an interview setting, questions can be tailored and areas of

132
interest can be probed deeply to yield a more accurate and complete reflection of
their views and experiences. Such in-depth information capture can increase the
value of data obtained (Shi, 2008).
In order to improve the data collection process, particular attention was paid
to two aspects of validity that could be problematic in qualitative studies. First,
construct validity is important to assure that questions captured the major dimensions
of the methodologies, practices and tools under study. Three different ways were
used to reduce problems of construct validity. First, each of the three areas of
interest was separated out, with a different set of participants and different questions
so that no area dominated the research to the exclusion of others. Second, early
symposia were used as opportunities to collect data on industry trends in general,
before focusing on the trends in the medical device field, so that all the dimensions
of this study were captured from early observations. Finally, most interviews were
conducted at fora that combined attendance from experts, practitioners and vendors
(tools) in all three areas of the study. The attendance of interested parties in all these
areas established a high degree of cross-referencing in the three areas of study,
significantly enhancing its construct validity. Furthermore, the information gained
from interviews could be evaluated in the context of presentations at the meetings to
assure that few important observations or trends would be missed. This wider
sampling reduced the probability that only one area of interest or one point of view
was captured.

133
A second aspect of validity that is important in research like this is content
validity, to assure that the agenda, constituent questions in the interview and other
interactions would provide insight into the key information needed to construct a
SRM model. Early symposia during initial exploration part of study were used as
opportunities to collect preliminary data to ensure that appropriate questions for the
interviews were captured to strengthen content validity. Two aspects of the study
design also helped to enhance the content validity, which could be compromised by
the relatively short period of interaction in a single interview. By holding interviews
at symposia or trade shows, advantage could be taken of the presentations that
generally preceded, and hence complimented, the interviews, because most interview
questions were already answered by the participant in that presentation. More time
was therefore available to ask questions about areas that were not covered explicitly
in the presentation or in the question and answer period after the presentation.
Secondly, even though most participants were found to have expertise, interest or
experience in only one aspect of the study, some had a good knowledge of more than
one area. This made it possible to obtain multiple points of data regarding more than
one facet of the study in the same interview or presentation sessions while capturing
the systemic perspective across study areas. Qualitative methods do, however,
demand strong observational, interviewing, interpretive and writing skills on the part
of a researcher, and this may prove to be a limiting factor especially in deriving
maximum information from early interviews.

134
Another challenge with content validity was ensuring sufficient participants
for a full and balanced view. For the part of the study that focused on
methodology/process, it appeared in early 2010 as if insufficient information would
be available within the medical device industry to identify new trends, and that ideas
about new/best practices would have to be found in other industries where their use
was much more common. However, as the study progressed, it became apparent that
change was occurring in medical device companies, and this change was attracting
the attention of regulators like the FDA. Thus, a strong surge was seen in the
numbers of related presentations in various fora attended by individuals from the
medical device industry in 2010-11, and enabled the study to assure good
participation from medical device industry.
The opposite problem was apparent when selecting a cross-section of
individuals knowledgeable about tools. From the beginning it was clear that this
area was changing rapidly, as reflected by the more than 50 respondents in this part
of the study, it was challenging to capture and prioritize all tool experts and vendors.
What was enormously helpful in establishing a baseline for discussion were the
white papers and other specialized documents to which our attention was drawn by
certain seminar presenters and interviewees. These documents, that listed different
types of tools according to their strengths or extent of use, allowed the identification
of some of the most popular tools that would be likely to interest potential users in
the medical device community. Because most participants viewed the tools
evaluated here as useful both for developing medical device software and for

135
developing software applications in general, we could be more confident that the
analyses done by others and published in the reviewed documents would be valid for
the medical device subsector as well as other software sectors more generally.
A final area that must be considered when critiquing the design of this study
is its external validity, or the likelihood that the data collected in the sampling of
experts in this study can be generalized to all experts in the field (Shi, 2008). This
could be a particular problem if the group of participants is too small or biased in a
particular direction. One method that is often used to increase external validity is to
assure representative sampling, often through randomized selection of participants.
However, in this exploratory research, random sampling was neither feasible nor
desired, because of specialized nature of the information that was sought. Instead,
experts in the area under study were deliberately sought out. Likewise, another
challenge in the study design concerned the reliability of the results. Reliability is
defined as the ability to repeat research and replicate findings, which can only be
gauged after a large number of views have been solicited, and in some cases it is
difficult to know when the point of saturation has been reached. In the present study,
attempts to mitigate these challenges were to increase the representation of
companies of different sizes and from diverse geographical areas by conducting
many interviews at popular trade meetings where most large companies are
represented. Even though the number of participants was by necessity relatively
small in comparison to population sizes typical with other methods such as
quantitative surveys, it was possible to ensure that the thought leaders were included.

136
In this study, such experts included individuals from Carnegie Mellon’s Software
Engineering Institute, standard bodies like AAMI, regulators like FDA, and leading
medical device companies such as GE Healthcare, St Jude Medical and Bio-Rad
Laboratories. In addition, the opportunity was taken to include a founding member
of Agile Alliance, a number of the largest tool vendors (e.g. Microsoft, IBM, HP),
and independent analysts from companies such as Forrester Research. However, this
approach may bias the results toward responses from individuals and companies with
the strongest software development practices, and may miss views more typical of
small companies. In this particular work we were attempting to find some of the best
or most robust practices in the industry, which typically are developed in large
companies with greater resources to hire capable software teams, devoting more of
their time to evaluations of new software methods, and researching and purchasing
different cutting edge software tools. Another limitation of this study that might
affect external validity is its concentration on US-based companies. It is possible that
companies in other countries have found different standards or tools that have not
been captured in the present research.
Consideration of Results
Agile as a Software Development “Methodology/Process”
The data collected in this study has identified that a family of software
development methodologies termed “Agile” has become popular in recent years in
the software development industry generally. Results from interviews further
suggest that medical device companies have recently started to explore the benefits

137
of this approach, while at the same time customizing this method to comply with the
regulatory requirements of the industry.
The features of Agile methodology identified as attractive by participants -
iterative/incremental capabilities allowing highest priority requirements to be
implemented first; continuous integration; greater ability to respond to change; easier
assessment of risk and impact of each/iterative change; better visibility regarding
degree of completion; efficient project management, repeated/extensive “peer-
review” through cohesive/collaborative behavior of teams; faster and less expensive
development cycles; closer collaboration between the programmer team and business
experts; emphasis on working, tested and shippable software from the beginning -
appear to be so strongly endorsed that this methodology is likely to be used more
extensively in future. Thus, it would seem that any risk management system for
software analysis should at least consider basing the proposed approach on some
combination of Agile and Waterfall methods. It is the intent in this chapter to
develop a practical model for cradle-to-grave risk management based on the findings
of this study. As a first step, it would seem wise to propose a combination of the
Waterfall and Agile methods as one feasible approach on which to base the model
(Figure 35), by developing a modified Agile method with as many Agile features as
possible, combined with traditional Waterfall activities as needed.

138
Design
Build
Test
Requirements
Deploy
Deploy
Build
Test
Design
Waterfall
Agile
Requirements
Design
Build
Test
Requirements
Deploy
Design
Build
Test
Requirements
Deploy

Figure 35: Waterfall vs. Agile Software Development Method

At the same time, it seemed clear from the data collected in this study that the
transition from industry’s traditional Waterfall and design controls approaches will
involve a significant change in culture, so that such an approach must be executed
gradually through planning, training, and mitigation of underlying compliance
implications.
One caution expressed by various experts is the concern that Agile methods
would foster a less disciplined approach in ways that might undermine several key
requirements of medical device regulations and standards, such as documentation,
formal approvals, processes, and plans. This concern has also been expressed by CD
of MKS (Doyle, 2010). Thus finding proper balance between misaligned creativity
with an Agile method and potential ossification with the Waterfall method would be
key, and promote value not by diminishing the existing value of the latter approach

139
but by enhancing the judicious incorporation of the former. Perhaps for these
reasons, the use of Agile for medical device software is still in the hands of early
adopters; it is relatively unproven in highly regulated software development
environment. The regulated industries can be imagined to generally lag in the
adoption of newer approaches, until they have been shown to be successful in other,
often less regulated development environments. Others working in regulated
environments such as SEI (SEI, 2011) and US Air Force STSC (STSC, 2011) are
also helping as change agents to bring the latest software development best practices
to the regulated environment. For example, CMMI and assurance cases discussed
earlier in this study were contributions made by SEI, while STSC (Software
Technology Support Center) is helping US Air Force and US DoD (Department of
Defense) to identify, evaluate and adopt technologies that improve software product
quality, production efficiency and predictability of software-intensive systems.
Each limitation of the Agile method in the regulated environment must be
assessed so that possible alternatives and modifications can be developed. One
example of how this kind of thought can produce a workable and perhaps better
outcome is illustrated by the response of MKS’s CD (Doyle, 2010), to the common
criticism that Agile methodologies lack independent V&V/testing to ensure that
medical devices meet user requirements through the end-user perspective. The
solution devised by MKS was to add “Independent” V&V to Agile iterations, which
was otherwise not practiced in pure Agile environment (Figure 36).

140
Design
Build
Test
Requirements
Design
Build
Test
Requirements
Deploy
Internally
Design
Build
Test
Requirements
Deploy V&V Independent V&V Independent
Stable
Build

Figure 36: Adding Independent V&V to Agile Method

As the medical device industry explores possible ways to use Agile
“Development” in a regulated environment, there are phases of SLC, notably those at
the very beginning of research, where regulations essentially do not apply and
benefits of the Agile methodology might be realized in its purest form. Research and
Development (R&D) has two distinct phases, and Agile used predominately in the
research phase could alleviate some of the unnecessary burden imposed by Waterfall
projects, that can be held in the requirement definition phase for years (Edwards
Lifesciences, 2010). Many companies make a mistake of locking themselves into a
design phase without an adequate research phase, where flexibility could be
valuable, believing that this is a regulatory requirement. However, this belief is
unnecessarily cautious. FDA clearly states in the preamble to 21 CFR 820:
It is not the intent of the FDA to apply the design control requirements to the
research phase. Instead the regulation requires the establishment of
procedures to ensure that whatever design is ultimately transferred to
production is, in fact, a design that will translate into a device that properly
performs according to its intended use and user needs. To assist FDA in
applying the regulation, manufacturers should document the flow of the
design process so that it is clear to the FDA investigator where research is
ending and development of design is beginning.

141
Developers and marketing personnel could benefit from quick prototyping as
they engage in their often frustrating quest to specify perfect, final and unchanging
detailed requirements for a product that does not exist in order to guide the Waterfall
methodology. Instead, many Agile iterations could be used to tease out core design
features in the form of a prototype in the research phase, before creating the
traditional software requirement and design specifications. To formalize the
transition from the research/prototype phase to the formal design control phase, a
documented phase review of the code developed during the research phase could be
conducted to bring the deliverables into a format familiar to the practitioners of
traditional Waterfall process, and to address any criticism from those in the company
that are skeptical of Agile development. Overall, the upfront 6-9 months often
needed for the initial research/prototyping exercise for a 2 year project could be
significantly beneficial and practical, and at the same time serve the purpose of
clarifying to FDA regulators the breakpoint at which the project transitions from the
research phase to the formal design controls phase.
Building an Integrated Risk Management System on Agile Methodology
The results of the research point to the usefulness of Agile methodology as a
foundation for medical device software. If we accept this platform as the foundation
of a software risk management framework, we need now to add appropriate risk
management practices to the framework. Research conducted to understand risk
management best practices showed that companies are typically continuing to apply
certain well understood and well tested best practices that almost certainly should be

142
added to the model. Two such sets of practices in particular, the risk-based software
development approach of IEC 62304 and the use of FMEA as a risk analysis tool, are
further discussed.
Integrating risk-based IEC 62304 and Agile software development
methods.
As noted earlier, one of the primary features of the Agile method is its
priority-based implementation of requirements/user-stories, with the highest priority
requirements implemented first (Figure 37). However, traditional practitioners of
Agile methodology typically use this priority-based approach to manage business or
project risk by delivering high-value software features first. On the other hand, in a
regulated environment such as medical device industry, the high priority attributes
may also be the avoidance of risks consequent to device malfunction, and its safe and
hazard-free operation. Therefore, the Agile method’s approach of “priority” can be
appropriately aligned with this objective by assigning highest priority to the
management of safety-related implementations that can pose serious hazards to a
patient. But how are the highest priority risks identified?

Design
Build
Test
1/3 Req. (User
Stories); High priority
Deploy
Design
Build
Test
Deploy
Design
Build
Test
Deploy
2/3 Req. (User
Stories); Med priority
1/3 Req. (User
Stories); High priority

Figure 37: Agile Method’s Priority-based Approach

143
IEC 62304:2006 is a particularly useful standard for implementing a “risk-
based” approach to medical device SLC processes. It drives the developer to modify
the degree of scrutiny paid to different components of the software system during
development and testing, proportional to their possible hazards. IEC 62304’s
“priority” is to concentrate most resources on software items with highest risk (Class
C, i.e. death or serious injury is possible if malfunction occurs), followed by
moderate risk (Class B, i.e. non-serious injury is possible), and then low-risk (Class
A, i.e. no injury or damage to health is possible) items.
Combining the priority-based approach of Agile with that of IEC 62304 has
the potential to improve systematically the risk management profile of medical
device software (Figure 38). Focusing on high-risk (Class C) software items
(units/modules, requirements/user-stories) in the earliest Agile sprints would not
only ensure that high-risk items are implemented first, but also that they will be
tested most during the course of each subsequent Agile sprint. Class B software
items are incrementally implemented in the next set of sprints, followed by Class C
in the last set of sprints.

HIGH-RISK
Design
Build
Test
HIGH-RISK Req.
Deploy
Mod-RISK
Design
Build
Test
Deploy
LOW-RISK
Design
Build
Test
Deploy
MOD.-RISK Req. LOW-RISK Req.

Figure 38: Agile Method Combined with IEC 62304 Risk-based Approach

144
Adding risk analysis tool FMEA to the model.
In order for the risk-based model combining IEC 62304 and Agile methods
discussed in last section to work, the risk of software items would have to be
determined first. The popular risk analysis tool, FMEA, can be employed effectively
for this purpose. As risks are identified and mitigated using FMEA, the residual risk
for software items can be characterized as high (C), moderate (B) or low (A) using
the nomenclature of IEC 62304.
The use of these methods does not by itself identify the designation of
software “items”. It first depends on software development team’s ability to create a
blueprint of their software design such as a Software Architecture Diagram (SAD),
or other feasible way to demonstrate how software system comes together from its
sub-systems and components, e.g. a set of features, use-cases, requirements or user-
stories. Regardless of the specific approach, the team should be able to use tools like
FMEA to characterize their Class A, B and C software “items”, and then use a
combined IEC 62304 and Agile approach for software development.
How would the risk management model operate from a practical point of
view? As a first step, the software product under consideration would undergo a risk
assessment process based on the intent of its use. The device would be classified
according to FDA guidelines as one of major, moderate or low Level of Concern
(LOC) (FDA, 2005b), and independently as Class A, B or C (not to be confused with
IEC 62304’s A, B and C classification of software items) for regulatory submission
purposes. With this beginning awareness of the risk classification of the product, the

145
software development team creates an FMEA at the system level (high-level). This
high-level analysis may be based on higher level system artifacts such as
features/use-cases/requirements/user-stories. Not only high risk devices, but devices
of all LOC could benefit from an FMEA at this level. Thereafter, if the LOC is
moderate or high, a mid-level FMEA could be developed at the sub-
system/component/unit/module level, and a series of low-level FMEAs could be
developed at the code level. Figure 39 shows this configuration illustratively, where
a top row of developmental phases/activities are matched with FMEAs in the bottom
row. Traceability is generally maintained between these entities so that the
implementation, test and risk status can be tracked.

Feature/Use-
case/Req.
FMEA
Design FMEA
Code-level
FMEA
Feature/Use-
case/User
Stories/Req.
Design/
Module/
Subsystem
Code/Software
item or task
Test Cases Traceability Traceability Traceability
Risk Score:
! " High
! " Medium
! " Low
Traceability
Risk Score:
! " High
! " Medium
! " Low
Risk Score:
! " High
! " Medium
! " Low
OR OR

Figure 39: Using FMEA to Identify High, Moderate and Low Risk Software Items

146
Furthermore, if an FMEA is developed at a high-level i.e. features/use-
cases/requirements/user-stories, and some of software items are being characterized
as high or moderate risk items, lower-level FMEAs, i.e. at design or code level, can
then be developed to pin-point the risk origins further. This can be useful to
differentiate riskier software items that require special attention from those that
require less attention. Otherwise, an item would inherit the risk classification of its
parent, as per IEC 62304. A well developed software architecture diagram could
help in structuring and pursuing this multi-level approach. Of course, FMEA can
always be complemented by other risk analysis tools such as FTA, as the developer
sees fit.
Modified Agile software development method for medical device
industry.
The framework that emerges thus far has several features that are specialized
for the medical device industry. The Agile methodology has been modified by
adding independent V&V (Figure 36), integrating the risk-based approach of IEC
62304 (Figure 38), and adding FMEA and potentially other risk management tools
(Figure 39). Other additions could be justified based on the inputs from participants
in chapter 4. Among these might be suggested the introduction and review of user
stories or requirements to assure that the product will mesh with clinical needs and
regulatory requirements by involving regulatory affairs or quality assurance
personnel for each Agile iteration, and planning each sprint as mini-Waterfall by
baselining DHF documentation to ensure compliance with FDA and other regulatory

147
requirements. This would be accomplished best if a part 11 (FDA, 2003) compliant
document control system could be integrated with the Agile process. Further
customization might include customer-developer interaction via demonstration of
working software after each sprint with particular regard to the identity of the
“customer” in that particular sprint. For example, it might make sense to have
development/test teams for earlier iterations, but clinically experienced individuals
and customer representatives, such as those in the organization’s marketing
department for later iterations. Careful attention to such customization and to the
feedback obtained for next iteration should greatly increase the likelihood of
achieving a fully compliant Agile software development framework appropriate for
the medical device industry (Figure 40).

148

Figure 40: Agile Software Development Method for Medical Device Industry

149
SRM Automation Using SDLC and ALM “Tools”
One of the most striking observations in this study was that seen in the third
part of the research, where a proliferation of tooling of many diverse types was seen.
These tools are designed to enhance the speed and effectiveness of the development
process by automating or electronically organizing certain processes (SDLC tools) or
by facilitating the organization of the overall enterprise as a whole (ALM tools). The
SRM framework that we are developing could be enhanced further through
automation with some of these tools. An attractive goal of integrating these SDLC
and ALM tools within a singular framework would be to provide end-to-end
automation of the SRM framework.
Effective cradle-to-grave automation is a desirable end result which can only
be achieved with the gradual maturation of the organization responsible for software
development organization. However, even before this difficult goal is achieved,
tooling can facilitate the development process for a wide variety of activities. For
example, tools can help to create and maintain traceability between requirements and
tests, and provide visual dashboards and metrics for project management. Tools can
also help in regulatory compliance by facilitating activities such as the generation of
documents using standard built-in templates, and then facilitating their electronic
review and approvals. Overall, tools greatly facilitate the delivery of high-quality,
compliant, safe and effective software consistently and efficiently. It makes the
software code less prone to errors made by individual developers, and sets uniform
expectations through repeatable and predictable outcomes.

150
A useful analogy for the potential of automating the “software development”
process is the example of the successful automation of drug manufacturing. The
pharmaceutical industry has leveraged the use of technology, machines, and
programs to automate the drug manufacturing process in ways that avoid manual
intervention. Likewise, in the software development process, many processes
historically done by the developer can now be done better by computerized program.
For example static code analysis and automated nightly builds and tests can be
“delegated” to the computer, freeing up time so that the developer’s creativity can
be focused on writing smart code.
Are SDLC and ALM tools effective?
Even though the tool vendors and analysts are recommending SDLC and
ALM tools to the industry, it remains unclear if these tools will be effective in
delivering their promises. Because many of these tools, especially of ALM tools, are
relatively new with no formal studies from analysts available, it can be hard to
substantiate this claim. However, an assessment has been recently conducted by a
software development company confused.com (Confused, 2010) on the contributions
of automated development tools in the software development projects. Their
assessment shows promising results such as increased revenue opportunities,
increased competitive advantage, build times slashed by half, build capacity
quadrupled, end-to-end builds taking ten minutes after implementation of full
automation in comparison to an hour in semi-automated state before the study, and
build server provisioning dropped from days to hours. Another evaluation is

151
currently ongoing at Vertafore, which provides build solutions for the independent
insurance channel. This company intends to report its analysis as it equips its
software development teams with ALM (Microsoft TFS) and SDLC (VSS,
Subversion, FogBugz, Project, Excel and Homegrown) tools, but their conclusions
were not yet published at the time of writing this thesis. Nonetheless, the software
developments teams seem to have become interested not only in using tools, but also
ensuring that their integration with the development process yields better overall
outcomes that can be quantified and reported.
Integrating tools with the Agile-based risk management system.
ALM tools go hand-in-hand with the new and most popular software
development methodologies like Agile, because managing multiple Agile projects
almost certainly will require automation (Forrester, 2010b). Otherwise manual status
sharing among various teams spread across several locations can be very time-
consuming. Using ALM tools, Agile teams can measure and track quality metrics
through dashboards. Agile projects require more frequent planning than traditional
development methods at various levels such as product/release, sprint/iteration and
individual level, so that the ability to improve the efficiency of such planning
exercises would be particularly important to assure the ultimate success of the
product in a timely manner. As organizations move from traditional to Agile
methodologies, or use a hybrid method including both, these tools can help
customize the chosen development process flow, and ensure its proper control and
compliance.

152
ALM tools help automate the whole lifecycle from cradle-to-grave by
providing a framework in which stand-alone SDLC tools from the same vendor are
already integrated, or those from third-parties can be integrated. The stand-alone
SDLC tools help software development teams to perform specific activities during
SDLC e.g. project, requirements, configuration, build, test, traceability and defect
management. Some SDLC tools, such as Eclipse IDE, were provided by the vendors
as stand-alone applications, while others were already integrated together within the
vendor’s ALM solution. For example, several of Microsoft’s SDLC tools such as
Visual Studio Test IDE and Lab Manager test management tools are integrated into a
comprehensive ALM platform called TFS (Team Foundation Server), which also
provides extensibility for other home grown and off-the-shelf tools from third-party
vendors to provide a cradle-to-grave solution for software development professionals
(Figure 41). Several other ALM tool vendors, notably Rally and VersionOne, also
provide similar solutions. A small minority of ALM vendors like MKS and Parasoft
have made an extra effort to reach medical device and other regulated industries with
their customized offerings catering to regulatory requirements of these industries.
For example, Parasoft ALM Concerto tool offers built-in configurable templates for
FDA compliance (Parasoft, 2011), and MKS ALM Integrity tool helps in
documentation and report generation throughout SDLC (MKS, 2011), among several
other design controls features aligned with the requirements of medical device
industry.

153

Figure 41: Microsoft’s SDLC Tools Integrated into ALM (TFS) (Malhotra, 2010)

Integrating Quality Management System (QMS) processes and tools.
In the medical device industry, software development is done under the aegis
of design controls requirements that are part of a larger QMS, which includes several
other controls such as records and documents including DHF, Corrective and
Preventive Action (CAPA), and requirements for complaints, recalls, corrections and
reporting (FDA, 1996b) (ISO, 2003). Therefore, it is highly desirable to have SDLC
and ALM tools integrated with the other QMS tools for document controls, adverse
event reporting, complaint handling and investigation, for total end-to-end process
automation, in line with FDA’s post-market expectations that were enunciated by
FDA participants in Chapter 4.

154
The following vendors of QMS tools or enterprise applications were found to
be popular in the medical device industry: 1) QMS (including CAPA and complaint
handling): ETQ Reliance, Pilgrim Software, MasterControl Inc, Oracle PQM; 2)
Training/Learning Management System (LMS): SABA; 3) Document Controls (&
DHF): Oracle PLM, Open Text Corp’s Livelink. These would seem to add value to
the framework that is described here in order to increase its effective and efficient
operation throughout QMS.
Automated Software Risk Management (SRM) Framework
The use of a software development methodology suggested here, such as the
Agile method, combined with various risk management practices, as well as SDLC
and ALM tools could produce one prototype of a fully automated, end-to-end SRM
framework (Figure 42). Such an automated SRM framework could benefit the
medical device industry in several ways, including 1) automated traceability between
various SDLC entities such as requirements, design, code, V&V/tests and defects, 2)
automation of SDLC activities of program/project, requirements, IDE, SCM, build,
V&V/test and defect management, as well as static code analysis and automation of
various tests and 3) automated linkages to various QMS tools and processes such as
document controls including reviews/approvals and compilation of technical
files/DHFs, complaint handling, CAPA and investigations. The prototype is not
intended to include all risk management practices and ALM/SDLC tools that could
be integrated into such a framework, but rather illustrates examples of how such
elements could be embedded. The model is developed for the purposes of

155
demonstration and as a beginning platform for more advanced models that might
later be developed in further studies, to progressively strengthen the SRM
framework, as new or improved practices become available or seem to meet specific
needs.
However, the use of tools to automate a software development methodology
must consider any future change in the development method, and provide flexibility
in removing non-value added activities and adding new best practices. Otherwise, an
organization’s significant investment of time and resources in the automation of
software development process could become a barrier to the opportunities of future
improvement, and cease to provide a real benefit in the long run. Other overheads
associated with the tools should also be mitigated, such as administration and
maintenance needs of newer tool versions, increased licensing costs, or lack of
support from the vendors with changing business environment.

156

Figure 42: Automated Software Risk Management (SRM) Framework for Medical Device Industry

157
SRM in Other High-risk and Regulated Industries
Using information gathered from software experts and users in the medical
device industry, this study has presented one way of developing a SRM framework,
through the integration of best practices in software development methodologies,
software risk management, as well as SDLC and ALM tools. Some of the other
ways to construct such a framework could possibly be found in regulated
environments to which medical device industry has much in common, such as
pharmaceutical, aerospace, automotive, and nuclear power industries. These
regulated industries must demonstrate to the regulatory authorities that the applicable
regulatory requirements are followed, and they generally develop applications that
are both complex and safety critical. Therefore, it only makes sense that these
industries learn from each other’s best practices in further improving their software
risk management. However, very few studies have made cross-industry comparisons
in which the medical device industry is compared to the other industries, with an
emphasis on methods for managing risks posed by software in various applications
(Freimut, 2001). In a rare example, a publication within the automotive industry
“What can the medical device industry teach us about safety” (Garnsworthy & Bell,
2004) makes such comparison to medical device industry:
The automotive industry is keen to introduce more advanced x-by-wire
systems. Many of these will be both complex and safety critical. The industry
will need to deal with the issue of designing such systems, and may benefit
from experience in other industries. While some lessons can be learnt from
aerospace, the completely different cost drivers and manufacturing volumes
will lead to different solutions. The medical device industry is arguably the
first industry that has needed to develop complex safety critical systems with

158
high software content. In this article we examine which lessons can be learnt.
Particularly in Europe, through the regulatory framework the medical device
industry has developed common safety standards for specific types of
devices. Approaches to risk management have changed from the single-fault
hypothesis to the risk-based. Many of the design drivers in medical devices
apply equally to automotive systems. This will in turn lead to similar
approaches to the design architecture being taken.

There have been other attempts to study the prevalence of specific risk
management techniques in various industries. Bennett et al. (1996) noted in the 90s
that risk analysis in the area of software was lagging compared to risk analysis for
hardware in general, while noting that its application in the chemical and nuclear
power industries was most well-developed, at least by using the uptake of tools such
as probabilistic risk assessment as a metric. It is unclear whether the same
conclusions are appropriate 15 years since that publication, given the very great
changes that have occurred in risk management practices in the medical device field,
driven in part by strong regulatory directives. Nevertheless, more recent articles
suggest that other industries still may be more sophisticated in their risk management
methods. For example, Lee (2006) developed a risk management model for the
aviation industry by evaluating the detectability, probability, criticality, and
frequency of hazardous events, and then integrating the fuzzy linguistic scale
method, FMECA and ALARP approach (Lee, 2006).
The space industry seems, from most literature, to be the place where the
longest history and greatest amount of work in the area of software risk management
is to be found. Cooper has recommended that the medical device software industry
take cues from space and defense industries (i.e. NASA and Department of Defense

159
respectively) in the rigor with which they pursue safety in life-critical software
systems (Cooper, 2006). There, emphasis has been placed on minimizing risks
associated with human error in design and operation of space systems (Nelson,
Haney, Ostrom & Richards, 1998). Formal instructions were given to program and
project management by NASA to apply risk management principles in development
projects. In order to train their personnel to accomplish this task, NASA developed a
course in conjunction with the Software Engineering Institute at Carnegie Mellon
University (Hammer & Rosenberg, 1999), and then reviewed the success of its first
five years of risk management program against its goals in further evaluating its
vision and mission (Rutledge, Stamatelatos, Chandler, Moyer, 2002). NASA
continues to gain valuable experience and knowledge from ongoing maintenance of
Space Shuttle Flight Software and new development projects like Cockpit Avionics
Upgrade, and applied the lessons learned from these initiatives to create a sustainable
and reliable model for development of other critical software projects, such as
Project Constellation (Gouvela, 2004). For the constellation program, NASA
developed software risk advisory tools to support Verification and Validation (V&V)
processes for flight projects. These tools used a value-based perspective to design
and optimize V&V processes through integration with different risk minimization
techniques for specific risks and overall flight risk (Madachy, Boehm, Richardson,
Feather & Menzies, 2007).
However, the regulatory requirements, resources, timelines and environment
under which sophisticated space systems are developed differ dramatically from

160
those in the medical device industry, where there is a strong emphasis must be placed
on speed of product release, clinical safety and reliance on small teams in often
poorly capitalized companies. It is hoped that as experience with risk management
methods matures in the medical device industry, practitioners may be in a better
position to implement some of the sophisticated tools that can be seen in the
literature of the space industry. Nonetheless, at this time, the medical device
industry is most comfortable to build on what it knows, reinforcing the importance of
consulting the users and experts in the medical device industry about current
practices, as we have here, in order to construct a system that might be practical and
acceptable.
Conclusions and Future Considerations
New risks have emerged as medical devices today rely extensively on
software for a wide variety of functions. Software integration in safety-critical
medical applications brings unique challenges, and the consequences of undesirable
device performance may be particularly serious to patients. However, software
based hazards are often not addressed comprehensively or systematically by the
existing risk management models. The results gathered in this study seem to suggest
a system in evolution, where software risk management is applied in a patchwork
manner. The need for a more systematic approach to develop an end-to-end model
for software risk management is clearly present.
In order to develop a systematic, software-focused risk management model,
this study has explored the best practices in software development

161
methodologies/processes, risk management across SLC, and various SDLC and
ALM tools. Some of the best practices used in other industries, such as the Agile
software development methodology/process, required modification to be compliant
with the regulatory requirements in the medical device industry. With these
modifications, it appeared possible to integrate a modified version of the Agile
software development methodology or process with various SLC risk management
best practices. This could be complemented by the automation of this platform
using SDLC and ALM tools, to create a cradle-to-grave SRM framework for use in
medical device industry.
The approach taken in this study to develop a SRM framework is one way of
achieving this objective. This study was not intended to provide an all inclusive list
of risk management practices that could be integrated into such a framework, but
rather to provide examples of how such approaches could be executed. Nonetheless,
it could serve as a basis for the development of more advanced models in further
studies, to strengthen the SRM framework progressively as new best practices
become available.
Another recommendation for future work would be to integrate further the
SRM framework developed in this study with quality management system (QMS)
processes and tools that are already very important in the medical device industry.
Currently, software development is done under the rubric of design controls
requirements in a QMS that includes several other controls such as record and
document controls including Design History File, Corrective and Preventive Action

162
(CAPA), and requirements for complaints, recalls, corrections and reporting (FDA,
1996b) (ISO, 2003). Therefore, it is highly desirable to integrate the SRM
framework with the other QMS processes and tools to produce an end-to-end quality
system that maximizes the use of already-present tools and resources. Some of these
QMS processes might include an organization-facing CAPA process, supplier-facing
processes to qualify and validate OTS software components, and customer-facing
processes such as complaint handling and investigation.
Last, some of the other ways to construct SRM frameworks could possibly be
found in regulated environments with which the medical device industry has much in
common, such as pharmaceutical, aerospace, automotive, defense/military, and
nuclear power industries. These regulated industries generally develop applications
that are both complex and safety critical, and have the same obligations to their
respective regulators to demonstrate that the applicable regulatory requirements are
fulfilled. Therefore, it is vital that these industries learn from each other’s best
practices in further improving their SRM models.

163
REFERENCES
AAMI. (2001). Medical device software-software life cycle processes, ANSI
(American National Standard)/ AAMI (Association for the Advancement of
Medical Instrumentation) SW68: Retrieved December 19, 2011 from
http://www.tech street.com/cgi-bin/detail?product_id=923487.

AAMI. (2004a). Medical device software risk management. AAMI/ANSI TIR 32.

AAMI. (2004b). Medical devices—Quality management systems — Guidance on the
application of ISO 13485:2003. AAMI/ANSI/ISO TR 14969.

AAMI. (2009). Human factors engineering: Design of medical devices. AAMI HE
75.

Agile Alliance. (2011). Agile Alliance: Retrieved December 19, 2011 from
http://www.scrumalliance.org/pages/what_is_scrum.

Agile for All. (2011). Agile for All: Retrieved December 19, 2011 from
http://www.agileforall.com/intro-to-agile/

Agile Manifesto. (2001). Agile Manifesto: Retrieved December 19, 2011 from
http://agilemanifesto.org/.

Akingbehin, K. (2005). Taguchi-based metrics for software quality. Computer and
Information Science, Fourth Annual ACIS International Conference, 713 –
716.

ANSI. (2001). Human factors design process for medical devices. ANSI/AAMI HE
74.

Arhire, R., & Tanase, G. (1995). Metrics of software complexity. International
Symposium of Economic Informatics, Bucharest, Romania, 141-145.

Baker, T. (2003). 2002 Medical device recalls and field corrections – Year in review.
Journal of Clinical Engineering. 28(4), 218-232.

Baker, T. (2004). 2003 Medical device recalls and field corrections – Year in review.
Journal of Clinical Engineering, 29(2), 90-105.

Bennett, J.C., Bohoris, G.A., Aspinwall, E.M., & Hall, R.C. (1996). Risk analysis
techniques and their application to software development. European Journal
of Operational Research, 95(3), 467-475.

164
Blake, N. (2003). Mistake proofing and redundancy in machine validation. Med
Device Technol, 14(1), 42-45.

Bliznakov, Z. (2007). Analysis and classification of medical device recalls. World
Congress on Medical Physics and Biomedical Engineering 2006, 14, 3782-
3785.

Bliznakov, Z., Pappous, G., Bliznakova, K., & Pallikarakis, N. (2003). Integrated
software system for improving medical equipment management. Biomed
Instrum Technol, 37(1), 25-33.

Blundell, J.K., Hines, M.L., & Stach, J. (1997). The measurement of software design
quality. Annals of Software Engineering, 4, 235-255.

Boehm, B. (1996). A Spiral Model of Software Development and Enhancement.
ACM 11(4),14-24.

Brewin, D., Leung, J., & Easty, T. (2001). Effectively utilizing device maintenance
data to optimize a medical device maintenance program. Biomed Instrum
Technol, 35(6), 383-390.

Burton, J., McCaffery, F., & Richardson, I. (2008). Improving software risk
management practices in a medical device company. International
conference on software process, ICSP, 24-35.

Chappell, D. (2008a). Tools for team development: Why vendors are finally getting
it right: Retrieved December 19, 2011 from
http://www.microsoft.com/global/applicationplatform/en/us/RenderingAssets
/Whitepapers/Tools%20for%20Team%20Development%20Why%20Vendor
s%20Are%20Finally%20Getting%20It%20Righ.pdf.

Chappell, D. (2008b). Application lifecycle management as a business process:
Retrieved December 19, 2011 from
http://www.davidchappell.com/ALMasABusinessProcess--Chappell.pdf.

Chappell, D. (2010). What is application lifecycle management?: Retrieved
December 19, 2011 from
http://www.davidchappell.com/writing/white_papers/What_is_ALM_v2.0--
Chappell.pdf.

Charette, R. (1997). Managing risk in software maintenance. IEEE Software, 14(3),
43–50.

165
CMDR. (1998). Canada Medical Devices Regulations SOR/98 -282 (52-56).

CMMI. (2011). Capability Maturity Model Integration (CMMI), Software
Engineering Institute (SEI), Carnegie Mellon: Retrieved December 19, 2011
from http://www.sei.cmu.edu/cmmi/.

CMS. (2005). Selecting a development approach. Centers for Medicate & Medicaid
Services (CMS). Department of Health and Human Services (HHS):
Retrieved December 19, 2011 from
https://www.cms.gov/SystemLifecycleFramework/downloads/SelectingDevel
opmentApproach.pdf.

Confused. (2010). Price comparison site increases revenue opportunities with
automated development tools: Retrieved December 19, 2011 from
http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=
4000007141.

Cooper, J., & Pauley, K. (2006). Healthcare software assurance. AMIA Annu Symp
Proc, 166-170.

Crumpler, E.S., & Rudolph, H. (1997). FDA software policy and regulation of
medical device software. Food Drug Law Journal, 52, 511-516.

Doyle, C. (2010). Making agile work in highly regulated environment. Better
Software Conference - Software Quality Engineering, Las Vegas NV.

Edward Lifesciences. (2010). Can and should agile be used for medical device
development? Absolutely! by Mike Dobbles: Retrieved December 19, 2011
from http://agile.dzone.com/articles/can-and-should-agile-be-used.

FDA. (1980). CPG Sec. 460.400 Computerized Prescription Recordkeeping by
Pharmacies: Retrieved December 19, 2011 from
http://www.fda.gov/ICECI/ComplianceManuals/CompliancePolicyGuidance
Manual/ucm074400.htm.

FDA. (1987). CPG Sec. 425.100 Computerized Drug Processing; CGMP
Applicability to Hardware and Software: Retrieved December 19, 2011 from
http://www.fda.gov/ICECI/ComplianceManuals/CompliancePolicyGuidance
Manual/ucm074372.htm.

166
FDA. (1996a). Medical Devices; Current Good Manufacturing Practice (CGMP)
Final Rule; Quality System Regulation: Retrieved December 19, 2011 from
http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidan
ce/PostmarketRequirements/QualitySystemsRegulations/MedicalDeviceQual
itySystemsManual/UCM122806.pdf.

FDA. (1996b). 21 CFR Part 820 Quality System Regulation: Retrieved December
19, 2011 from
http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CF
RPart=820&showFR=1.

FDA. (1997a). Design Control Guidance for Medical Device Manufacturers:
Retrieved December 19, 2011 from
http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedo
cuments/ucm070627.htm.

FDA. (1997b). Reviewer Guidance for a Premarket Notification Submission for
Blood Establishment Computer Software: Retrieved December 19, 2011 from
http://www.fda.gov/downloads/BiologicsBloodVaccines/GuidanceComplianc
eRegulatoryInformation/OtherRecommendationsforManufacturers/Memoran
dumtoBloodEstablishments/UCM062208.pdf.

FDA. (1999a). Managing the Risks from Medical Product Use: Creating a Risk
Management Framework: Retrieved December 19, 2011 from
http://www.fda.gov/downloads/safety/safetyofspecificproducts/ucm180520.p
df.

FDA. (1999b). Guidance for Industry, FDA Reviewers and Compliance on Off-The-
Shelf Software Use in Medical Devices: Retrieved December 19, 2011 from
http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidan
ce/GuidanceDocuments/ucm073779.pdf.

FDA. (1999c). Guidance for Industry - Computerized Systems Used in Clinical
Trials: Retrieved December 19, 2011 from
http://www.fda.gov/regulatoryinformation/guidances/ucm126402.htm.

FDA. (2000). Guidance for Industry and FDA Premarket and Design Control
Reviewers. Medical device use safety: Incorporating HFE into risk
management: Retrieved December 19, 2011 from
http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidan
ce/GuidanceDocuments/ucm094461.pdf.

167
FDA. (2002). General Principles of Software Validation; Final Guidance for Industry
and FDA Staff: Retrieved December 19, 2011 from
http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidan
ce/GuidanceDocuments/ucm085371.pdf.

FDA. (2003). Guidance for Industry Part 11, Electronic Records; Electronic
Signatures — Scope and Application: Retrieved December 19, 2011 from
http://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInfor
mation/Guidances/ucm072322.pdf.

FDA. (2005a). Guidance for Industry - Cybersecurity for Networked Medical
Devices Containing Off-the-Shelf (OTS) Software: Retrieved December 19,
2011 from
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Guidanc
eDocuments/ucm077812.htm.

FDA. (2005b). Guidance for the Content of Premarket Submissions for Software
Contained in Medical Devices: Retrieved December 19, 2011 from
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Guidanc
eDocuments/ucm089543.htm.

FDA. (2007a). Draft Guidance for Industry: Blood Establishment Computer System
Validation in the User's Facility: Retrieved December 19, 2011 from
http://www.fda.gov/downloads/BiologicsBloodVaccines/GuidanceComplianc
eRegulatoryInformation/Guidances/Blood/ucm078815.pdf.

FDA. (2007b). Guidance for Industry - Computerized Systems Used in Clinical
Investigations: Retrieved December 19, 2011 from
http://www.fda.gov/OHRMS/DOCKETS/98fr/04d-0440-gdl0002.PDF.

FDA. (2009). Recognized Consensus Standards: Recognition Number 5-50: IEC
62366, Medical devices - Application of usability engineering to medical
devices: Retrieved December 19, 2011 from
http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandards/simplesearch.
cfm?db=std&id=26639.

FDA. (2010a). Infusion Pump Software Safety Research at FDA: Retrieved
December 19, 2011 from
http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/General
HospitalDevicesandSupplies/InfusionPumps/ucm202511.htm.

168
FDA. (2010b). Examples of Reported Infusion Pump Problems: Retrieved December
19, 2011 from
http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/General
HospitalDevicesandSupplies/InfusionPumps/ucm202496.htm.

FDA. (2010c). Guidance Document – About Guidance: Retrieved December 19,
2011 from
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Guidanc
eDocuments/ucm108067.htm.

FDA. (2010d). Guidance for Industry and FDA Staff - Total Product Life Cycle:
Infusion Pump - Premarket Notification [510(k)] Submissions: Retrieved
December 19, 2011 from
http://www.fda.gov/medicalDevices/DeviceRegulationandGuidance/Guidanc
eDocuments/ucm206153.htm .

FDA. (2011). Human Factors and Medical Devices. Human Factors Program at
FDA: Retrieved December 19, 2011 from
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/HumanF
actors/default.htm.

Feldmann, R.L., Shull, F., Denger, C., Host, M., & Lindholm, C. (2007). A survey of
software engineering techniques in medical device development. Joint
Workshop on High Confidence Medical Devices, Software, and Systems and
Medical Devices Plug-and-Play Interoperability, Boston, MA, 46-54.

Fletcher, S.K., Jansma, R.M., Lim, J.J., Halbgewachs, R., Murphy, M.D., & Wyss,
G.D. (1995). Software system risk management and assurance. New Security
Paradigms Workshop, 66 – 74.

Forrester. (2008). European Software Configuration Management Tool Adoption
Trends: Retrieved December 19, 2011 from
http://www.forrester.com/rb/Research/european_software_configuration_ma
nagement_tool_adoption_trends/q/id/47831/t/2.

Forrester. (2010a). Microsoft Ups The ALM Ante With Its Bet On Teamprise:
Retrieved December 19, 2011 from
http://www.forrester.com/rb/Research/microsoft_ups_alm_ante_with_bet_on/
q/id/55748/t/2.

169
Forrester. (2010b). The Forrester Wave: Agile Development Management Tools, Q2
2010: Retrieved December 19, 2011 from
http://www.forrester.com/rb/Research/wave&trade%3B_agile_development_
management_tools,_q2_2010/q/id/48153/t/2.

Forrester. (2010c). Agile development: Mainstream adoption has changed agility:
Retrieved December 19, 2011 from
http://www.forrester.com/rb/Research/agile_development_mainstream_adopt
ion_has_changed_agility/q/id/56100/t/2.

Freimut, B. (2001). An industrial case study of implementing software risk
management. Proceedings of the 8th European software engineering
conference held jointly with 9th ACM SIGSOFT international symposium on
Foundations of software engineering, Vienna, Austria, 277 – 287.

Garnsworthy, J., & Bell, P. (2004). What can the medical device industry teach us
about safety? Proceddings of the 3rd IMechE Automobile Division Southern
Centre Conference on: Total Vehicle Technology; Finding the Radical,
Implementing the Practical, Brighton, UK, 73-81.

GE Healthcare. (2010). GE Healthcare Goes Agile by Andrew Deitsch and Ross
Hughes: Retrieved December 19, 2011 from http://drdobbs.com/architecture-
and-design/228300298?cid=nl_ddjmdev_2010-12-08_html.

GHTF. (2005). Implementation of risk management principles and activities within a
Quality Management System. GHTF, SG3/N15/R8.

Gouvela, J. (2004). An introduction to flight software development: FSW today,
FSW 2010. STAR 44(16), 1.

Hammer, T.F., & Rosenberg, L. (1999). Continuous risk management: A NASA
program initiative. STAR 37(22).

Hartkopf, S. (2003). From a single discipline risk management approach to an
interdisciplinary one: adaptation of FMEA to software needs. Software
Technology and Engineering Practice, Eleventh Annual International
Workshop, 204 – 213.

IEC. (2006a). Medical device software – Software life cycle processes. IEC 62304.

IEC. (2006b). Fault tree analysis (FTA). IEC 61025.

170
IEC. (2007). Medical devices -- Application of usability engineering to medical
devices, IEC 62366.

IEC. (2010). Medical Electrical Equipment – Part 1-6: General Requirements for
Safety – Collateral Standard: Usability. IEC 60601-1-6.

IOM. (1999). To Err Is Human: Building a Safer Health System. Washington, DC:
National Academy Press.

ISO. (2003). Medical devices -- Quality management systems -- Requirements for
regulatory purposes. ISO 13485.

ISO. (2003-11). Information technology – Process assessment – Part 1-9. ISO/IEC
15504-2.

ISO. (2008a). Systems and software engineering – Software life cycle processes.
ISO/IEC 12207.

ISO. (2008b). Systems and software engineering – System life cycle processes.
ISO/IEC 15288.

ISO. (2009). Medical devices - Application of risk management to medical devices.
ISO 14971.

ISO. (2011). Systems and software engineering - Systems and software assurance -
Part 2: Assurance case. ISO/IEC 15026-2.

Israelski, E., & Muto, W. (2004). Human factors risk management as a way to
improve medical device safety: a case study of the therac 25 radiation therapy
system. Jt Comm J Qual Saf, 30(12), 689-695.

Jones, P.L., Jorgens III, J., Taylor Jr, A.R., & Weber, M. (2002). Risk management
in the design of medical software systems. Biomed Instrum Technol, 36(4),
237-266.

Jordan, P. (2006). Standard IEC 62304 – Medical device software – Software
lifecycle processes. Institution of Engineering and Technology Seminar on
Software for Medical Devices, London, UK, 41-47.

Jorgens, J., & Greenbaum, J. (1998). Software quality assurance and system safety. J
Clin Eng, 13(3), 195-199.

171
Koru, G., El Emam, K., Neisa, A., & Umarji, M. (2007). A survey of quality
assurance practices in biomedical open source software projects. J Med
Internet Res, 9(2), e8.

Krasner, J. (2010). Critical issues facing medical device manufacturers. EMF’s guide
for medical device developers. Embedded Market Forecasters: Retrieved
December 19, 2011 from http://www.embeddedforecast.com.

Lanthropm J., & Watson, S. (1982). Decison analysis for the evaluation of risk in
nuclear waste management. Journal of the Operational Research Society, 3,
407-418.

Larrick, K. (2007). Performance vs. design. Understanding software validation
requirements. Biomed. Instrum. Technol. 41(3): 236-237.

Lee, S., & Choi, B. (2000). Establishment of the software quality metrics for a
software development process. Journal of KISS: Software and Applications
(South Korea), 27(3), 217-26.

Lee, W.K., (2006). Risk Management modeling in aviation safety management.
Journal of Air Transport Management, 12(5), 267-273.

Leveson, N.G. (1995). Software: System Safety and Computers. New York: Addison-
Wesley.

Leveson, N.G., & Turner, C.S. (1993). An investigation of the Therac-25 accidents.
IEEE Computer, 26(7), 18-41.

Li, W. (2000). Software product metrics. IEEE Potentials, 18(5), 24-27.

Liu, X.F., Kane, G., & Bambroo, M. (2003). An intelligent early warning system for
software quality improvement and project management. Tools with Artificial
Intelligence, Proceedings 15th IEEE International Conference, 32 – 38.

Madachy, R., & Boehm, B., Richardson, J., Feather, M., & Menzies, T. (2007).
Value-Based Design of Software V&V Processes for NASA Flight Projects.
AIAA SPACE 2007 Conference & Exposition, Long Beach, CA.

Malhotra, V. (2010). Testing in a agile world. Microsoft ALM Summit, Seattle WA.

Mallory, S. (1993). Building quality into medical product software design. Biomed
Instrum Technol, 27(2), 117-135.

172
Matsuo, E. (2000). Risk assessment in incremental software development. STAR,
38(2).

McCormick, N. (1981). Reliability and Risk Analysis; methods and Nuclear Power
Applications London: Academic Press.

MDD. (1993). EU Medical Devices Directive 93/42/EEC.

MKS. (2011). ALM tool Integrity: Retrieved December 19, 2011 from
http://www.mks.com/solutions/by-industry/medical-devices.

Mizuno, O., Shigematsu, E., Takagi, Y., & Kikuno, T. (2002). On estimating testing
effort needed to assure field quality in software development. Software
Reliability Engineering, ISSRE. Proceedings of 13th International
Symposium, 139 – 146.

Mojdehbakhsh, R., Subramanian, S., Vishnuvajjala, R., Tsai, W.T., & Elliott, L.
(1994a). Process for software requirements safety analysis. Proceedings of
the International Symposium on Software Reliability Engineering, ISSRE,
Monterey, CA, 45-54.

Mojdehbakhsh, R., Tsai, W.T., Kirani S., & Elliott L. (1994b). Retrofitting software
safety in an implantable medical device. IEEE Software, 11(1), 41-50.

Murff, H., Patel, V., Hripcsak, G., & Bates, D. (2003). Detecting adverse events for
patient safety research: a review of current methodologies. J Biomed Inform,
36(1-2), 131-143.

Nagappan, N. (2004). Toward a Software Testing and Reliability Early Warning
Metric Suite. Proceedings of 26th International Conference on Software
Engineering, Los Alamitos, CA, 60-62.

Nelson, W., Haney, L., Ostrom, L., & Richards, R. (1998). Structured methods for
identifying and correcting potential human errors in space operations. Acta
Astronaut, 43(3-6), 211-222.

NRC. (2007). “National Research Council (NRC) Report: Software for Dependable
Systems: Sufficient Evidence?”.

Parasoft. (2011). ALM tool Concerto: Retrieved December 19, 2011 from
http://www.parasoft.com/jsp/products/concerto/fda_medical.jsp.

Parrish, E.A. (1998). Computer 31(6).

173
Patton, M. (2002). Qualitative Evaluation and Research Methods. Thousand Oaks,
CA: Sage.

Pew, R., & Mayor, A. (2007). Human-system integration in the system development
process: A new look. Washington, DC: National Academies Press.

Pigoski, T. (1996). Practical Software Maintenance: Best Practices for Software
Investment. JohnWiley & Sons, Inc.

Rakitin, R. (2006). Coping with defective software in medical devices. Computer
(USA), 29(4), 40-45.

Ramachandra, P, Haeng-Kon, K., Byeongdo, K., Yan, H., Lee, R.(2006). Risk
Management through Architecture Design. Software Engineering Research,
Management and Applications. Fourth International Conference, 386 – 395.

Roumm, A., Sciamanna, C., & Nash, D. (2005). Health care provider use of private
sector internal error-reporting systems. Am J Med Qual, 20(6), 304-312.

Roy, G. (2004). A risk management framework for software engineering practice.
Australian Software Engineering Conference (ASWEC'04), 60.

Rutledge, P.J., Stamatelatos, M.G., Chandler, F.T., & Moyer, R.W. (2002). The
NASA Risk Management Program. Joint ESA-NASA Space-Flight Safety
Conference, Noordwijk, Netherlands, 486, 11-16.

Schneidewind, N.F. (2001). Investigation of the risk to software reliability and
maintainability of requirements changes. Software Maintenance.
Proceedings. IEEE International Conference, 127 – 136.

Scrum Alliance. (2011). Scrum Alliance: Retrieved December 19, 2011 from
http://www.scrumalliance.org/.

SEI. (2011). Software Engineering Institute (SEI), Carnegie Mellon: Retrieved
December 19, 2011 from http://www.sei.cmu.edu/.

Seilevel. (2011). Seilevel Requirements Management Tool Evaluation: Retrieved
December 19, 2011 from
http://requirements.seilevel.com/blog/2011/06/seilevel-requirements-
management-tool-evaluation-part-1.html.

174
Sharma, V.S., & Jalote, P. (2006). Stabilization Time - A Quality Metric for
Software Products. Software Reliability Engineering, ISSRE. 17th
International Symposium, 45 – 51.

Shi, L. (2008). Health Services Research Methods. Albany, NY: International
Thompson Publishing.

Simmons, J. (2001). How root-cause analysis can improve patient safety. Qual Lett
Healthc Lead, 13(10), 2-12.

Sommerville, I. (2000). Software Engineering. Boston, MA: Addison Wesley.

Storey, N. (1996). Safety-Critical Computer Systems. Essex, England: Addison
Wesley Longman.

STSC. (2011). United States Air Force, Software Technology Support Center
(STSC): Retrieved December 19, 2011 from http://www.stsc.hill.af.mil/.

Subramanian, S. (1995). A framework for designing safe software systems.
Proceedings of Nineteenth Annual International Computer Software and
Applications Conference (COMPSAC), Dallas, TX, 409-14.

Thomas, R. (2006). 2005 Medical device recalls and field corrections – Year in
review. Journal of Clinical Engineering, 31(3), 177-201.

Troisi, N. J. (1988). Software quality assurance in the healthcare environment. US
Healthc, 5(9), 41-42, 44.

Tsai, W.T., Mojdehbakhsh, R., & Rayadurgam, S. (1997). Experience in capturing
requirements for safety-critical medical devices in an industrial environment.
Proc. High-Assurance Systems Engineering Workshop, Washington D.C.,
32–36.

Tsai, W.T., Mojdehbakhsh, R., & Zhu, F. (1998). Ensuring system and software
reliability in safety-critical systems. Application-Specific Software
Engineering Technology, ASSET. Proceedings. IEEE Workshop, 48 – 53.

Tsai, W.T., Bai, X., Paul, R., & Yu, L. (2001). Scenario-based functional regression
testing. 25th Computer Software and Applications Conference (COMPSAC),
Chicago IL, 496 – 501.

175
USDOT. (2007). Systems Engineering for Intelligent Transportation Systems: An
Introduction for Transportation Professions. U.S. Department of
Transportation. Federal Highway Administration. Federal Transit
Administration. Jan 2007.

Visaggio, G. (1997). Structural information as a quality metric in software systems
organization. 13th International Conference on Software Maintenance
(ICSM), 92-99.

Voas, J.M., & McGraw, G. (1998). Software Fault Injection, New York: John Wiley
& Sons Inc.

Vogel, D. (2006). Software safety for every phase of software development. Biomed
Instrum Technol, 40(4), 309-314.

Voke Research. (2010). Market Mover Array Report: Testing Platforms: Retrieved
December 19, 2011 from
http://www.microsoft.com/presspass/itanalyst/docs/08-11-10MMA.PDF.

Wallace, D. & Kuhn, D. (1999). Lessons from 342 medical device failures. Proc. 4th
Annu. IEEE Intl. Symp. On High-Assurance Systems Engineering,
Washington D.C., 123– 131.

Ward, J., & Clarkson, P.J. (2004). An analysis of medical device related errors:
prevalence and possible solutions. Journal of Medical Engineering and
Technology, 28(1), 2-21.

Webster, K.P.B., de Oliveira, K.M., & Anquetil, N. (2005). A risk taxonomy
proposal for software maintenance. Software Maintenance, ICSM.
Proceedings of the 21st IEEE International Conference, 453 – 461.

Wood, B. (1999). Software risk management for medical devices. J. Med Device
Diagn Ind, 21(1), 11.

Xu Ru-Zhi, X., Pei-Yao, N., Ying S., Le-Hong, Q., & Yun-Ting, L. (2005).
Optimizing software process based on risk assessment and control. Computer
and Information Technology, CIT. The Fifth International Conference, 896 –
900.

Yin, R. (2003). Case Study Research: Design and Methods. Thousand Oaks, CA:
Sage.

176
APPENDIX A
LIST OF SEMINARS FROM WHICH STUDY DATA WAS COLLECTED OR
INTERVIEWS CONDUCTED
a. Agile Leadership Forum (March’10), Santa Clara CA – (ALF-Mar2010)
b. IQPC's 13th Annual Software Design for Medical Devices Conference
(May’10), San Diego, CA - (IQPC-2010)

c. Better Software Conference, Software Quality Engineering (June’10), Las
Vegas NV – (BSC-2010)

d. Agile Leadership Forum (July’10), Santa Clara CA – (ALF-Jul2010)
e. ALM tools Summit for Microsoft Platform (Nov’10), Seattle WA – (ALM-
2010)

f. FDA and Industry Leaders on Agile & Risk-Based Processes and Global
Quality Systems (March’11), Baltimore MD – (AGILE & RM-2011)

g. IQPC's 14th Annual Software Design for Medical Devices Conference
(May’11), San Diego, CA – (IQPC-2011)

h. Better Software Conference, Software Quality Engineering (June’11), Las
Vegas NV – (BSC-2011)

177
APPENDIX B-1
INTERVIEW QUESTIONNAIRE: SOFTWARE DEVELOPMENT
METHODOLOGY/PROCESS AND RISK MANAGEMENT PRACTICES
a. Explain this methodology (or risk management practice)?*
b. What benefits does it have over traditional methodologies e.g. Waterfall, or
V-model?

c. What are the disadvantages?
d. Can this be used in regulated industries, e.g. medical device industry? What
changes or customization, if any, are needed in regulated industries and
why?*

e. Are these recognized as best practices in the industry?*
f. Which industries and companies are employing these? Is it being used in
medical device and other regulated industries? Why or why not?*

g. Are these recognized by regulators, e.g. FDA?*
h. How does this methodology/practice help in risk management? Does it have
other benefits to enhance safety and risk profile of the product being
developed using this process (or risk management practice)?*

i. Can this methodology be automated, fully or partially, e.g. through the usage
of tools?

j. Do you have any study or metrics to support the claims of benefits of this
methodology (or risk management practice)?*

* = For study on risk management practices. All questions (including those marked
with *) applicable for software development methodology/process study.

178
APPENDIX B-2
INTERVIEW QUESTIONNAIRE: SOFTWARE DEVELOPMENT AND
LIFECYCLE MANAGEMENT TOOLS
a. Which segment of SLC is covered by this tool?
b. What are the other competing tools in this segment?
c. What are advantages and disadvantages of this tool over its alternatives (i.e.
compared to development environment where such tools are not used e.g.
performing function manually or by other alternative means)?

d. What segments of SLC are not covered by this tool?
e. Which tools are available in other segments of SLC, and how can they be
integrated to this tool?

f. How does this tool help in risk management? Which other benefits does it
have to enhance safety and risk profile of the product being developed using
this tool?

g. Which companies currently use this tool?*
h. Is this tool being used in regulated industries? Is this being used in medical
device industry?*

i. Does this tool need customization for regulated industries? What are the
differences in its usage in regulated industry over others?*

j. Does this tool need customization for your workflow/need, compared to its
out-of-box version?**

k. How much effort is needed in tool’s validation/maintenance to ensure
regulatory compliance?**

l. Is this tool validated to all applicable regulatory requirements, e.g. intention
of use, Part 11, etc? Do you provide records of validation to the users for
their files?*

179
m. Are there case studies or metrics available to demonstrate the effectiveness of
this tool or other tools in this segment, or overall usage of various tools in
SCL processes?

n. Do you have any unmet need in terms of tooling in SLC processes?**
o. Do have any thoughts where the tools development industry is headed next?
What changes are you expecting in tools usage or design in the future?*

* = Only for tools Suppliers/Vendors and 3
rd
party/Independent Analysts, ** = Only
for tools Users and Regulators; Other questions are applicable to all tools study
participants.

180
APPENDIX C-1
DETAILS OF STUDY PARTICIPANTS AND DATA COLLECTION:
SOFTWARE DEVELOPMENT METHODOLOGY/PROCESS
* Participant: For certain participants, initials are used instead of their full names.
In those cases, either the permission to publish their names was not explicitly
obtained, or it was not clear if they wanted their names to be disclosed in this
research. However, most of the study participants shared their information or
opinions publicly, e.g. in various fora listed in Appendix A, and it did not appear that
they wanted to maintain privacy or confidentiality of their identity or information.

** Participant Type: m1 = Expert/Consultant; m2 = User/Practitioner; m3 =
Regulator/Standards Body; m4 = 3rd-party/Independent Analyst.

*** Study Location: See Appendix A for details

181
Table C-1: Details of Study Participants and Data Collection: Software Development Methodology/Process

# Participant*
Participant
Type* Participant Affiliation & Details
Participant
Industry
Study
Location*** Method used
1 Richard
Chapman
m3 FDA (Division of Software and Electrical
Engineering, Office of Science and Engineering
Laboratories)
Medical
Device
IQPC-2010 Seminar
presentation
2 John Murray m3 FDA (Medical Device Software Compliance
Expert)
Medical
Device
AGILE &
RM-2011
Seminar
presentation (&
Interview)
3 LP m3 AAMI Medical Device Software Standards
Committee, Agile TIR Task Group; Also
Director of Software (St Jude Medical)
Medical
Device
AGILE &
RM-2011
Seminar
presentation (&
Interview)
4 LM m2 St. Jude Medical (Director of Software
Development, Cardiac Rythum Management
Division)
Medical
Device
AGILE &
RM-2011
Seminar
presentation (&
Interview)
5 Will
Stubblebine
m2 Bio-Rad Laboratories (Group Software
Development Manager)
Medical
Device
AGILE &
RM-2011
Seminar
presentation (&
Interview)
6 Jeff Dere m2 Applied Biosystems - Life Technologies
(Director, Software Technologies)
Medical
Device
AGILE &
RM-2011
Interview (&
Seminar
Presentation)
7 Karen Davies m1 CCS (Certified Compliance Solutions) Inc, San
Diego CA
Medical
Device
In-person
(Mar 18’11 &
Mar 30’11)
Interview
8 KG/Others m2 Varian Medical Systems, Palo Alto CA
(Software Project Manager)
Medical
Device
In-person
(April, 2010)
Interview

182
Table C-1, continued

# Participant*
Participant
Type* Participant Affiliation & Details
Participant
Industry
Study
Location*** Method used
9 DS/Others m2 Illumina Inc, San Diego CA (Sr Engineer,
Software Development; and Scrum Master)
Medical
Device
In-person (Jan
6, 2011)
Interview
10 AD & RH m2 GE Healthcare Medical
Device
Online Position Paper
11 MD m2 Edwards Lifesciences (Director of
Engineering)
Medical
Device
Online Position Paper
12 Andy Hunt
(founding
member of
Agile Alliance)
m1 Pragmatic Bookshelf (Partner) Software BSC-2011 Interview
13 Joy Beatty m1 Seilevel - requirements defined (Vice President
of Blue Ocean Strategy)
Software BSC-2011 Interview
14 Hillel Glazer m1 Entinex (Principal and CEO) Software BSC-2011 Interview (&
Seminar
Presentation)
15 PM m1 PEM Systems (Principal) Software BSC-2011 Seminar
presentation
16 FS m1 Hewlett Packard Software BSC-2011 Seminar
presentation
17 MP m1 SEI (Software Engineering Institute) Medical
Device
IQPC-2011 Seminar
presentation

183
Table C-1, continued

# Participant*
Participant
Type* Participant Affiliation & Details
Participant
Industry
Study
Location*** Method used
18 Colin Doyle m1 MKS Inc Medical
Device
BSC-2010 Seminar
presentation
19 Dave West (&
Tom Grant)
m4 Forrester Software ALF-Jul2010 Publication/
Interview

184
APPENDIX C-2
DETAILS OF STUDY PARTICIPANTS AND DATA COLLECTION: RISK
MANAGEMENT PRACTICES
* Participant: For certain participants, initials are used instead of their full names.
In those cases, either the permission to publish their names was not explicitly
obtained, or it was not clear if they wanted their names to be disclosed in this
research. However, most of the study participants shared their information or
opinions publicly, e.g. in various fora listed in Appendix A, and it did not appear that
they wanted to maintain privacy or confidentiality of their identity or information.

** Participant Type: p1 = Expert/Consultant; p2 = User/Practitioner; p3 =
Regulator/Standards Body.

*** Study Location: See Appendix A for details

185
Table C-2: Details of Study Participants and Data Collection: Risk Management Practices

# Participant*
Participant
Type** Participant Affiliation & Details
Participant
Industry
Study
Location*** Method used
1 Ed Israelski
a1
p1 Abbott (Director, Human Factors)
a1
1
st
topic – HFE
Medical Device AGILE &
RM-2011
Interview (& Seminar
presentation)
2 Charles
Weinstock
p1 Software Engineering Institute (SEI)
Carnegie Mellon
Medical Device AGILE &
RM-2011
Interview (& Seminar
presentation)
3 Richard C.
Chapman
p3 FDA (Division of Software and Electrical
Engineering, Office of Science and
Engineering Laboratories)
Medical Device IQPC-2010 Seminar presentation
4 Larry Spears p3 FDA (Deputy Director Office of
Compliance)
Medical Device AGILE &
RM-2011
Seminar presentation
5 TH p2 GE Medical (Director, Risk
Management)
Medical Device AGILE &
RM-2011
Interview (& Seminar
presentation)
6 Dan Olivier
b1
p1 CCS (Certified Compliance Solutions)
Inc, San Diego CA
b1
1
st
topic – IEC 62304)
Medical Device AGILE &
RM-2011
Interview (& Seminar
presentation)
7 Thuy Cook p2 Covidien, Respiratory and Monitoring
Solutions (Thuy Cook)
Medical Device IQPC-2011 Seminar presentation
8 SM p2 Center for applied health sciences,
Virginia Tech
Medical Device AGILE &
RM-2011
Seminar presentation

186
Table C-2, continued

# Participant*
Participant
Type** Participant Affiliation & Details
Participant
Industry
Study
Location*** Method used
9 Dan Olivier
b2
p1 CCS (Certified Compliance Solutions)
Inc, San Diego CA
b2
2
nd
topic – Safety, RM preventive
actions)
Medical Device AGILE &
RM-2011
Seminar presentation
10 Ed Israelski
a2
p1 Abbott (Director, Human Factors)
a2
2
nd
topic – FMEA/FTA
Medical Device AGILE &
RM-2011
Seminar presentation
11 JP
c1
p1 Coveros Inc
c1
1
st
topic (Agile project RM)
Software BSC-2011 Seminar presentation
12 Hagai Livni p2 Given Imaging (Head of Software
Validation)
Medical Device IQPC-2011 Seminar presentation
13 JG p1 Grove Consultants (Julie Gardiner) Software BSC-2010 Seminar presentation
14 JP
c2
p1 Coveros Inc
c2
2
nd
topic (Risk based testing)
Software BSC-2010 Seminar presentation

187
APPENDIX C-3
DETAILS OF STUDY PARTICIPANTS AND DATA COLLECTION: SDLC AND
ALM TOOLS
* Participant; Participant Affiliation & Details: For certain participants, initials
are used instead of their full names. In those cases, either the permission to publish
their names was not explicitly obtained, or it was not clear if they wanted their
names to be disclosed in this research. However, the names of most of the
participants were less relevant than that of participant’s affiliation i.e. tool
suppliers/vendors, and those details are provided therein. For the same reason,
several participants are identified as ‘NA’, and details of tool suppliers/vendors are
included instead.

** Participant Type: t1 = Supplier/Vendor; t2 = User; t3 = Regulator; t4 = 3rd-
party/Independent Analyst.

*** Study Location: See Appendix A for details. Additionally, “Online” may
include e-mails, phone, website exploration, and other interactions with the
participant.

188
Table C-3: Details of Study Participants and Data Collection: SDLC and ALM Tools

# Tools Participant*
Participant
Type**
Participant Affiliation
& Details*
Participant
Industry
Study
Location*** Method used Other Details
1 Code
Analysis
Richard
Chapman
t3 FDA (Division of
Software and
Electrical
Engineering)
Medical
Device
IQPC-2010 Seminar
presentation

2 Req Mgmt/
SCM/Code
Analysis
Jerry
Krasner
t4 Embedded Market
Forecasters
Medical
Device
Online Publication
3 SCM JH t4 Forrester Software ALF-Jul2010 Publication
4 ALM DW & JH t4 Forrester Software ALF-Jul2010 Publication
5 ALM DW t4 Forrester Software ALM-2010 Seminar
presentation

6 ALM JH t4 Forrester Software ALF-Jul2010 Publication
7 ALM TL & LD t4 voke Research Software ALM-2010 Publication
8 ALM GH/Others t2 Varian Medical
Systems
Medical
Device
In-person (Apr
1’11)
Interview
9 ALM DS/Others t2 Illumina Inc. Medical
Device
In-person (Jan
6’11)
Interview
10 ALM Rep (Booth) t1 VersionOne Software BSC-2011 Interview www.versionone.com/
Product/
11 SCM Rep (Booth) t1 Perforce Software Software BSC-2010/11 Interview www.perforce.com/
product/product_features
12 ALM DR t1 ThoughtWorks
Studios
Software BSC-2010/11 Interview www.thoughtworks-
studios.com/

189
Table C-3, continued

# Tools Participant*
Participant
Type**
Participant
Affiliation &
Details*
Participant
Industry
Study
Location*** Method used Other Details
13 ALM, SCM AG t1 Collabnet Inc. Software BSC-2011 Interview www.open.collab.net/
products/
14 Test/Code/
Req Mgmt
MT t1 LDRA Software BSC-2010/11 Interview www.ldra.com/
15 ALM JH t1 TechExcel Software BSC-2010/11 Interview www.techexcel.com/
products/index.html
16 Project
Mgmt
GM t1 QSM Software BSC-2010/11 Interview www.qsm.com/tools
17 Project/
test/Defect/D
oc Mgt
JE t1 Hansoft Software BSC-2010/11 Interview www.hansoft.se/
solutions.html
18 ALM Mark
Johnson
t1 Parasoft Medical
Device
BSC-2010/11 Interview www.parasoft.com/
jsp/products/concerto/alm.jsp?
itemId=473
19 ALM Jim Lange t1 MKS Inc. Medical
Device
BSC-2010/11 Interview &
Seminar
presentation
download.mks.com/
downloads/demos/test/index.h
tml
20 ALM JT t1 Rally Software BSC-2010 Interview www.rallydev.com/
5601_Rally_15.html
21 ALM TD t1 HP Software BSC-2010 Interview
22 Code
Analysis
MC t1 Klocwork Software BSC-2010 Interview www.klocwork.com/
products/insight-pro/

190
Table C-3, continued

# Tools Participant*
Participant
Type**
Participant
Affiliation &
Details*
Participant
Industry
Study
Location*** Method used Other Details
23 Req/Test/
Change
Mgmt
David James t2 Covidien,
Respiratory and
Monitoring
Solutions
Medical
Device
IQPC-2011 Seminar
presentation

24 ALM DC t1 DC & Associates Software ALM-2010 White paper
25 ALM DC t1 DC & Associates Software ALM-2010 White paper
26 ALM PP t1 Microsoft Software ALM-2010 Seminar
presentation
msdn.microsoft.com/
en-us/vstudio/ff637362
27 ALM confused.com t2 confused.com Software ALM-2010 Seminar
presentation
www.microsoft.com/
casestudies/Case_Study_Detail.
aspx?casestudyid=4000007141
28 ALM Vertafore t2 Vertafore Software ALM-2010 Seminar
presentation

29 ALM,
various
NA t1 Microsoft Software Online Website
30 Req Mgmt NA t1 IBM Rational
Reqpro
Software Online Website
31 Req Mgmt NA t1 IBM Rational
Doors
Software Online Website
32 IDE NA t1 Oracle Fusion
Middleware
Jdeveloper
Software Online Website www.oracle.com/
technetwork/developer-
tools/jdev/overview/index.html

191
Table C-3, continued

# Tools Participant*
Participant
Type**
Participant Affiliation
& Details*
Participant
Industry
Study
Location*** Method used Other Details
33 IDE NA t1 eclipse Mylyn Software Online Website eclipse.org/mylyn/
34 SCM NA t1 Subversion Software Online Website subversion.apache.org
35 SCM NA t1 AccuRev Software Online Website www.accurev.com
36 SCM NA t1 IBM Rational
ClearCase
Software Online Website
37 Build
Mgmt
NA t1 cruisecontrol Hudson Software Online Website
38 Build
Mgmt
NA t1 anthillpro Software Online Website www.urbancode.com/
html/products/anthillpro/defau
lt.html
39 Build
Mgmt
NA t1 apache ant Software Online Website ant.apache.org
40 Build
Mgmt
NA t1 electriccloud Software Online Website www.electric-
cloud.com/products/
electricaccelerator_demo/Acc
eleratorDemo_Mar09.html
41 Test/V&V NA t1 TestManager Software Online Website
42 Test/V&V NA t1 IBM Rational Quality
Center
Software Online Website
43 Defect
Mgmt
NA t1 IBM Rational
ClearQuest
Software Online Website
44 Defect
Mgmt
NA t1 Bugzilla Software Online Website www.bugzilla.org

192
Table C-3, continued

# Tools Participant*
Participant
Type**
Participant
Affiliation &
Details*
Participant
Industry
Study
Location*** Method used Other Details
45 Defect
Mgmt
NA t1 fitnesse Software Online Website fitnesse.org
46 Defect
Mgmt
NA t1 JIRA Software Online Website www.atlassian.com/
software/jira/overview
47 ALM NA t1 IBM Rational Software Online Website
48 Other NA t1 Replay
solutions
Software Online Website www.replaysolutions.com/
technology/demo-video.php
49 Other NA t1 dynaTrace Software Online Website www.dynatrace.com/
twominutedemo/?mkt_tok=3RkM
MJWWfF9wsRoiv6zfLqzsmxzEJ
8v47uoqWLHr08Yy0EZ5VunJE
UWy2YIARA%3D%3D
50 Other NA t1 S2
Technologies
Software Online Website www.s2technologies.com
51 QMS NA t1 ETQ Software Online Website www.etq.com
52 QMS NA t1 MasterControls Software Online Website www.mastercontrol.com
53 QMS NA t1 Pilgrim Software Online Website www.pilgrimsoftware.com
54 QMS NA t1 Camstar Software Online Website www.camstar.com
55 QMS NA t1 Oracle Software Online Website education.oracle.com/
pls/web_prod-plq-
dad/db_pages.getCourseDesc?dc=
D66846GC10&p_org_id=400&la
ng=US

193
Table C-3, continued

# Tools Participant*
Participant
Type**
Participant
Affiliation &
Details*
Participant
Industry
Study
Location*** Method used Other Details
56 LMS NA t1 SABA Software Online Website www.saba.com/
lms-learning-management-
system
57 DMS NA t1 LiveLink Software Online Website www.opentext.com/
2/global/products/products

Abstract (if available)

Linked assets