A software risk management capability model for medical device software

The Medical Device industry is currently one of the fastest growing industries in the world and a guarantee of the integrity of medical device software has become increasingly important. Failure of the software can have potentially catastrophic effects, leading to injury of patients or even death. Consequently there is a tremendous onus on medical device manufacturers to demonstrate that sufficient attention is devoted to the area of software risk management throughout the software lifecycle. Failure to do so can lead to a lack of approval from the various regulatory bodies with a consequent surrender of the right to market the device in a particular country. Several different standards, guidance papers and industry guides exist which make it difficult to guarantee conformance in all cases. This diverse set of requirements can make software risk management difficult and this thesis examines the possibility of a unified approach whilst investigating the relevance of the Capability Maturity Model Integration (CMMI®) SPI model to the regulatory requirements. It is demonstrated that existing SPI models are not comprehensive enough to satisfy medical device safety requirements and an alternative is proposed. The research presented in this thesis develops a software Risk Management Capability Model (RMCM) for the medical device sector, which meets medical device regulatory requirements and the CMMI® Software Process Improvement (SPI) risk management practices. The RMCM has been evaluated within a medical device company producing medical device software. During the creation of the model a mapping has been performed between medical device regulations and the CMMI® guidelines for software risk management. The research identifies the potential strengths and weaknesses of the CMMI® risk management process area in the specific context of medical device software. The research also identifies weaknesses of current medical device software regulations, through the analysis of the CMMI® SPI model

Risk management capability model (RMCM) for the development of medical device software

Failure of medical device (MD) software can have potentially catastrophic effects, leading to injury of patients or even death. Therefore regulators penalise MD manufacturers who do not demonstrate that sufficient attention is devoted to the areas of hazard analysis and risk management (RM) throughout the software lifecycle. This paper has two main objectives. The first objective is to compare how thorough current MD regulations are with relation to the Capability Maturity Model Integration (CMMI®) in specifying what RM practices MD companies should adopt when developing software. The second objective is to present a Risk Management Capability Model (RMCM) for the MD software industry, that is geared towards improving software quality, safety and reliability. Our analysis indicates that 41 RM sub-practices would have to be performed in order to satisfy MD regulations and that only an additional 8 sub-practices would be required in order to satisfy all the CMMI® level 1 requirements. Additionally, MD companies satisfying the CMMI® goals of the RM process area by performing the CMMI® RM practices will not meet the requirements of the MD software RM regulations as an additional 20 MD specific sub-practices had to be added to meet the objectives of RMCM

Development and evaluation of a risk management capability model (RMCM) for the medical device industry

Development and evaluation of a risk management capability model (RMCM) for the medical device industr

Software risk management in medical device systems

Software risk management in medical device system

Improving software risk management in a medical device company

Software Risk Management (RM) within Medical Device (MD) companies is a critical area. Failure of the software can have potentially catastrophic effects, leading to injury of patients or even death. Therefore regulators penalise MD manufacturers that do not devote sufficient attention to the areas of hazard analysis and RM throughout the software lifecycle. This paper describes the experience of a MD software development organization when they engaged in a research project to improve their RM practices. We explain how this was achieved through the development of a software process improvement RM model that integrates regulatory MD RM requirements with the goals and practices of the Capability Maturity Model Integration (CMMI). This model is known as the Risk Management Capability Model (RMCM). The authors describe the complete project lifecycle and evaluate the success of the project

Design and implementation of a hospital quality assurance program (H-QAP)

The purpose of this paper is to present the development of a Hospital Quality Assurance Program, H-QAP. People and Medical Devices, including software, cannot be separated in the healthcare environment, and clinical and software engineering staff are often expected to work together to ensure software systems success. However, this often results in conflicting definitions of success. H-QAP was developed as a result of researching the source of problems characteristic of the live clinical environment. It is designed to overcome these conflicts through compliance with evidence-based best practice in the management of patients and software systems

A process framework for global software engineering teams

.Context: Global Software Engineering (GSE) continues to experience substantial growth and is fundamentally different to collocated development. As a result, software managers have a pressing need for support in how to successfully manage teams in a global environment. Unfortunately, de facto process frameworks such as the Capability Maturity Model Integration (CMMI ) do not explicitly cater for the complex and changing needs of global software management. Objective: To develop a Global Teaming (GT) process area to address specific problems relating to temporal, cultural, geographic and linguistic distance which will meet the complex and changing needs of global software management. Method: We carried out three in-depth case studies of GSE within industry from 1999 to 2007. To supplement these studies we conducted three literature reviews. This allowed us to identify factors which are important to GSE. Based on a gap analysis between these GSE factors and the CMMI , we developed the GT process area. Finally, the literature and our empirical data were used to identify threats to software projects if these processes are not implemented. Results: Our new GT process area brings together practices drawn from the GSE literature and our previous empirical work, including many socio-technical factors important to global software development. The GT process area presented in this paper encompasses recommended practices that can be used independently or with existing models.We found that if managers are not proactive in implementing new GT practices they are putting their projects under threat of failure. We therefore include a list of threats that if ignored could have an adverse effect on an organization’s competitive advantage, employee satisfaction, timescales, and software quality. Conclusion: The GT process area and associated threats presented in this paper provides both a guide and motivation for software managers to better understand how to manage technical talent across the globe

Map of Horn of Africa region showing key locations and also migration patterns for Somali refugees.

<p>Map of Horn of Africa region showing key locations and also migration patterns for Somali refugees.</p