Developing a configuration management capability model for the medical device industry
Fergal Mc Caffery*
Lero – The Irish Software Engineering Research Centre, University of Limerick, Ireland
E-mail: Fergal.McCaffery@lero.ie
*Corresponding author
Gerry Coleman
Dundalk Institute of Technology, Dundalk, Ireland
E-mail: gerry.coleman@dkit.ie
Abstract: Software is becoming an increasingly important aspect of medical devices and medical device regulation. Software enables highly complex systems to be built. However, complexity is the enemy of safety, therefore strict adherence to well documented processes is important within the domain of medical device software. Medical devices can only be marketed if compliance and approval from the appropriate regulatory bodies of the Food and Drug Administration (FDA) is achieved. This paper outlines the development of a Configuration Management Capability Model (CMCM). The CMCM is a Software Process Improvement (SPI) model specifically dedicated to Configuration Management (CM) for the medical device industry. This paper details how medical device regulations may be satisfied by adopting relevant practices from the Capability Maturity Model Integration (CMMI®) CM process area. It also investigates how the CMMI® CM process area may be extended with additional practices that are outside the remit of the CMMI®, but are required in order to satisfy Medical Device Regulatory (MDR) guidelines.
Keywords: configuration management; CM; medical device; software process improvement model; SPI; capability maturity model integration; CMMI®.
Reference to this paper should be made as follows: Mc Caffery, F. and Coleman, G. (XXXX) ‘Developing a configuration management capability model for the medical device industry’, Int. J. Information Systems and Change Management, Vol. X, No. Y, pp.XXX–XXX.
Biographical notes: Fergal Mc Caffery is a Senior Research Fellow with Lero – The Irish Software Engineering Research Centre. He has both an industrial and academic background. His current research interests include the development of a software development framework for the medical device industry, software process improvement frameworks and assessments and global software development.
Gerry Coleman is a Member of the Computing and Maths Department at
Dundalk Institute of Technology (DKIT) where he specialises in teaching 
Software Engineering and Project Management. He is also a Director of the Software Technology Research Centre (SToRC) at DKIT and a Member of the Irish Software Engineering Research Centre. His research involves examining the development and evolution of software processes in small software development companies.
1 Introduction
Software is becoming an increasingly important aspect of medical devices and medical device regulation. Medical devices can only be marketed if compliance and approval from the appropriate regulatory bodies of the Food and Drug Administration (FDA) (FDA Regulations, 1997), and the European Council (1993) under its Medical Device Directives (MDD) is achieved. Medical device companies must produce a design history file detailing the software components and processes undertaken in the development of their medical devices. Producing such a file requires medical device organisations to track and control software and associated work products. This can be achieved using a Configuration Management (CM) system. Hass (2003) defines CM as “the unique identification, controlled storage, change control, and status reporting of selected intermediate work products, product components and products during the life of a system”. Because of the safety-critical nature of medical device software, and the requirements stipulated by the relevant regulatory bodies, it is essential that a highly effective CM process is in place within medical device companies.
However, many medical device software producers wish to go further than merely comply with regulations by examining the nature of their software development processes to see what improvement is possible. In support of this, research carried out by the Software Engineering Institute (SEI) (Herbsleb et al., 1994), on Software Process Improvement (SPI) programmes within a range of software development organisations, reported: an average improved yearly productivity of 35%; an early defect detection (defects discovered pretest) gain per year of 22%; a yearly reduction in the time to market for products of 19%; a yearly reduction in post-release defect reports of 39% and an overall return upon the investment in SPI of five times the investment. In pursuing these potential gains, we investigate how software development best practice can be effectively harmonised with regulatory compliance.
This paper will investigate how thorough current medical device regulations are in relation to specifying what CM practices medical device companies should adopt when developing software. This will be achieved through comparing current medical device regulations and guidelines for CM against the formally documented software engineering ‘best practices’ of the CMMI® (Chrissis et al., 2007) for the CM process area.
Section 2 will examine the need for Configuration Management Capability Model (CMCM) and how similar SPI-based models have been used within other safety-critical and highly regulated software industries. Section 3 will describe the development of the CMCM. Section 4 is the main section of this paper and details the mappings that were performed between the medical device regulations and the CMMI® for CM. This section describes the content of the CMCM. It details what additional practices have to be added
to the CMMI® CM process area in order to satisfy medical device regulations, as well as what CMMI® practices are not required in order to satisfy basic MDR requirements. How could benefit by adopting some of the CMMI® practices that are not deemed necessary by medical device regulations and are therefore outside the remit of CMCM. Finally, Section 5 contains our conclusions from this research.
2 Related work and contribution
Though GAMP (ISPE, 2001) details CM practices that medical device companies may adopt in order to comply with medical device regulations, no documentation exists within the medical device domain in relation to how such practices could be improved by incorporating practices from formal software engineering SPI models for CM.
However, if we investigate other regulated industries such as the Automotive and Space industries, we realise that they are not content with merely satisfying regulatory standards, but have proactively developed domain-specific SPI models. These models have been created so that they may continuously improve the development of their information systems to achieve higher levels of safety, greater efficiency and a faster time to market, whilst seamlessly satisfying regulatory requirements. The major process improvement frameworks that currently exist, namely ISO/IEC 15504 (2003) and CMMI®, do not specifically address regulatory requirements. Therefore, the automotive industry established a new SPI model based upon ISO/IEC 15504 and this is now referred to as Automotive SPICE (2005). Likewise, another new model, SPiCE for SPACE (Cass et al., 2004), based on ISO/IEC 15504, was developed specifically for the space industry. Both of these models contain reference and assessment information in relation to how companies may improve their CM practices within their domain.
This study does not address the issue of developing an entire SPI model for the medical device industry (this is discussed in Mc Caffery et al. (2005)), but instead focuses upon the individual process area of CM, thus addressing an opportunity to integrate the regulatory issues and SPI mechanisms to achieve improvements that are critical to the CM of software for medical devices.

3 CMCM development
The CMCM was initiated by work (Mc Caffery et al., 2004, 2006) that one of the authors performed whilst based at the Centre for Software Process Technologies at the University of Ulster. This author is now progressing this work with Lero. The initial research work was assisted by a pilot of five medical device companies and a notified standards body (all based in Northern Ireland). Each of the five companies expressed a desire to have access to a CM model that would incorporate SPI practices and could fulfil the relevant MDR requirements. However, this work is now being extended to include  medical device companies in the Republic of Ireland.
The CMCM is flexible in that relevant elements of the model may be adopted as required to provide the most significant benefit to the business. The model is based on the Capability Maturity Model Integration (CMMI®). The regulations used to extend the CMMI® framework are those of the FDA and the ANSI/AAMI SW68 (2001) standard (SW68) (Medical device software – Software life cycle processes).

The CMCM provides a means of assessing the software engineering capability for the CM process area in relation to software embedded in medical devices (FDA/CDRH, 1999, 2002, 2005). The CMCM has been developed to promote SPI practices into the CM process adopted by medical device companies. This is an attempt to improve the effectiveness and efficiency of CM within medical device companies through investigating the mapping of MDR guidelines against the CMMI® CM process area. The mappings between the MDR guidelines and the CMMI® practices for the CM process resulted in the CMCM being composed of a number of goals and practices. Goals and practices may be either generic (relating to the entire organisation) or specific (relating directly to the CM process). The CMCM determines what parts of the CMMI® CM process area are required to satisfy medical device regulations. It also investigates the possibility of extending the CMMI® CM process area with additional practices that are outside the remit of the CMMI®, but are required in order to satisfy MDR guidelines.
The CMCM will enable medical device companies to measure their organisational CM capability and to track their progression against the following capability levels:
•	Level Med: companies must demonstrate that the CM process area satisfies the goals and performs the practices required to achieve FDA regulatory compliance.
•	Level 1: companies must demonstrate that the CM process area satisfies level Med and the CMMI® capability level 1 goal of performing the CMMI® base practices.
•	Level 2: companies must demonstrate that the CM process area satisfies level 1 and additionally the CMMI® capability level 2 generic goal of Institutionalising a Managed Process.
•	Level 3: companies must demonstrate that the CM process area satisfies level 2 and additionally the CMMI® Generic Goal to Institutionalise a Defined Process (CMMI® Generic Goal 3).
•	Level 4: companies must demonstrate that the CM process area satisfies level 3 and additionally the CMMI® Generic Goal to Institutionalise a Quantitatively Managed Process (CMMI® Generic Goal 4).
•	Level 5: companies must demonstrate that the CM process area satisfies level 4 and additionally the CMMI® Generic Goal to Institutionalise an Optimising Process (CMMI® Generic Goal 5).
4 Mapping the FDA and SW68 against the CMMI®
The FDA provides little insight into how CM should be performed other than to state that a CM plan should exist and that this should be adopted to manage configuration items for medical device software. Therefore, in order to gain a greater understanding of the CM guidelines that medical device companies must follow in order to achieve regulatory compliance, we referred to the medical device software life cycle processes (SW68) standard. This standard was created for use in the medical device sector based on the life cycle requirements of ISO/IEC 12207 (1995, 2004). In order to achieve this, FDA regulations and SW68 guidelines (for the rest of this paper, we refer to these together as medical device standards) were mapped against the goals and practices of the CMMI® CM process area.
This section will identify the goals, practices and subpractices that exist within the CMCM. Tables will be used to demonstrate how the CMCM is composed of CMMI® CM practices and MDR requirements. Subpractices that are displayed in italics in the tables are subpractices that are not present in the CMMI®, but are required in order to fulfil MDR requirements. Discussion will be provided outlining the RMCM capability levels associated with each subpractice.
The CMCM has three Specific Goals (SG). These are as follows: SG1: Establish Baselines, SG2: Track and Control Changes and SG3: Establish Integrity. To meet each of these goals, it is necessary for a number of specific practices to be performed.
4.1 SG1: Establish Baselines
In order to fulfil SG1: ‘Establish Baselines’ the following specific practices have to be performed: identify configuration items, establish a Configuration Management System (CMS) and create or release baselines.
Table 1 provides the complete list of the CMCM practices, subpractices and their associated capability level for establishing baselines.

Table 1	CMCM subpractices for specific goal 1 – Establish Baselines
Practice	CMCM Subpractice	Subpractice	Source CMCM
number	level
Identify	1	Select the configuration items and	MDR and	Med
configuration	the work products that compose	CMMI
items	them based on documented criteria
2	Assign unique identifiers to	MDR and	Med
configuration items	CMMI
3	Specify when each configuration	MDR and	Med
item is placed under CM	CMMI
4	Specify the important characteristics CMMI	1
of each configuration item
5	Identify the owner responsible for	CMMI	1
each configuration item
6	Identify off the shelf components	MDR	Med
Establish	7	Establish a mechanism to manage	CMMI	1
a CMS	multiple control levels of CM
8	Store and retrieve configuration	MDR and	Med
items in the CM system	CMMI
 9                       Share and transfer configuration
                         items between control levels within
                         the CM system
10                      Store and recover archived
                         versions of configuration items	CMMI	1
CMMI	1	
11	Store, update and retrieve	MDR and	Med
CM records	CMMI
12	Create CM reports from the CM	CMMI	1
system

Table 1	
CMCM subpractices for specific goal 1 – Establish Baselines (continued)		
Practice	CMCM Subpractice
number	Subpractice	Source	CMCM level	
	13	Preserve the contents of the CM system	CMMI	1	
	14	Revise the CM structure as necessary	CMMI	1	
Create or
release baseline	15	Obtain authorisation from the CCB before creating or releasing baselines of configuration items	CMMI	1	
	16	Create or release baselines only from configuration items in the	CMMI	1	
		CM system			
	17	Document the set of configuration items that are contained in a baseline	MDR and CMMI	Med	
	18	Make the current set of baselines readily available	CMMI	1	

Table 2, summaries the CMCM specific goal 1 (Establish Baselines) that was produced from mapping of the medical device CM standards against the CMMI® specific goal 1 (SG1: ‘Establish Baselines’).

Table 2	Summary of CMCM specific goal 1 – Establish Baselines

Practice	CMCM
subpractice numbers	No. of CMMI® subpractices	No. of CMMI® subpractices required to meet regulatory medical device requirements	No. of additional subpractices required to meet regulatory medical device requirements	
Identify configuration items	1–6	5	3	1	
Establish a	7–14	8	2	0	
CMS					
Create or release
baseline	15–18	4	1	0	
Total		17	6	1	

It may be observed from Table 2 that not all of the subpractices of this CMMI® goal will have to be performed in order to satisfy the medical device standards (in fact only 6 of the 17 CMMI® subpractices will have to be performed). However, in order to satisfy the objectives of the CMCM, an additional (medical device specific) subpractice had to be added (i.e. to satisfy goal 1 of the CMCM).
4.1.1 CMCM subpractices related to identifying configuration items
4.1.1.1 Level Med subpractices Upon analysis, it was discovered that, in order to adhere to the medical device standards in relation to identifying configuration items, only three (i.e. subpractices 1, 2 and 4) out of the five subpractices for the associated CMMI® specific practice, relating to identifying configuration items, are required (i.e. subpractices 1–5 inclusive). However, an additional subpractice is required in order to identify Off-the-Shelf components (subpractice 6). Therefore, four of the six CMCM subpractices are required to fulfil the medical device standards for identifying configuration items.
4.1.1.2 Level 1 subpractices The CMMI® guidelines request that important characteristics of the configuration items (e.g. author, file type, etc.) should be specified (subpractice 3). However, this is not specified within the medical device standards and so should be included. Additionally, only the CMMI® requires that each configuration item should be assigned an owner (subpractice 5).
4.1.2 CMCM subp ractices for establishing a CMS
4.1.2.1 Level Med subpractices The main differences here are that the CMMI® requests the usage of multiple control levels of CM, as well as archiving and restoration procedures to be in place. Therefore, only two (i.e. subpractices 8 and 11) of the eight CMMI® subpractices are required for establishing a CMS (i.e. subpractices 7–14 inclusive).
4.1.2.2 Level 1 subpractices The CMMI® model guidelines specify that it should be possible to provide different levels of control for CM (subpractice 7). Different levels of configuration control could be a useful feature of a CMS within a medical device company as they provide increased levels of security as a product approaches completion. However, this is not included in the medical device standards.
The CMMI® additionally details that stored configuration items may be shared and transferred between control levels (subpractice 9). The storage and recovery of archived versions of configuration items is an important part of any CMS and is therefore listed as a guideline within the CMMI® model (subpractice 10), however, there are no equivalent guidelines within the medical device standards.
A desirable feature of a CMS is to produce the capability to automatically generate configuration reports (subpractice 12). This feature is not only attractive from a usability perspective, but also more crucially in terms of the accuracy of configuration reports, as reports generated by the system will contain the exact details of the configuration. This is particularly important in the safety-critical domain of medical device software. However, the medical device standards do not include this guideline.
Another important part of a CM process is to provide guidance in terms of backing up the CM files to an archive and putting in place procedures for restoration and recovery (subpractice 13) (the CM procedure specified in the medical device standards do not specify this, however the CMMI® requests it). Additionally, the CMMI® requests that the CM structure should be revised when necessary (subpractice 14) (this is not specified within the medical device standards).

4.1.3 CMCM subpractices related to establishing a CMS
4.1.3.1 Level Med subpractices Table 1 illustrates that in order to adhere to the medical device standards, only one (i.e. subpractice 17) of the four subpractices required for the associated CMMI® practice are necessary (i.e. subpractices 15–18 inclusive).
4.1.3.2 Level 1 subpractices Only the CMMI® CM process specifies the importance of obtaining the necessary approval before creating or releasing baselines (subpractice 15) (this is particularly surprising given the safety-critical nature of medical device software) and nothing should be included in a baseline without the consent of the relevant stakeholders. This subpractice would help ensure that unintended or unauthorised changes are not included as part of the baseline. Likewise, only the CMMI® specifies that the baseline should limit inclusion to those items that are stored in the CM system (subpractice 16). The CMMI® model also specifies that the current set of baselines should be listed and made readily available (subpractice 18). This guideline is not included in the medical device standards.

4.2 SG2 Track and Control Changes
In order to fulfil SG2: ‘Track and Control Changes’, the following specific practices have to be performed: track change requests and control configuration items.
Table 3 provides the complete list of the CMCM practices, subpractices and their associated capability level for tracking and controlling changes.
Table 3	CMCM subpractices for specific goal 2 – Tracking Change Requests

Practice	CMCM subpractice
number	
Track change requests	19	
	20	
	21	
	22	
	23	
Control configuration items	24	

Subpractice	Source	CMCM
level
Initiate and record change requests MDR and	Med
in the change request database	CMMI
Analyse the impact of changes and MDR and	Med
fixes proposed in the change	CMMI
requests.
Review change requests that will	MDR and	Med
be addressed in the next baseline	CMMI
with those who will be affected
by the changes and get their
agreement.
Track the status of change requests MDR and	Med
to closure.	CMMI
Each upgrade, bug fix or patch for MDR	Med
OTS software shall be evaluated,
and the evaluation shall be
documented
Control changes to configuration	MDR and	Med
items throughout the life of the	CMMI
product

Table 3	CMCM subpractices for specific goal 2 – Tracking Change Requests (continued)
Practice CMCM subpractice	Subpractice	Source	CMCM
number	level

MDR and Med CMMI

25	Obtain appropriate authorisation
before changed configuration items are entered into the CM system

CMMI	1

26	Check in and check out
configuration items from the CM system for incorporation of changes in a manner that maintains the correctness and integrity of the configuration items
                                    27	Perform reviews to ensure that	MDR and	Med
changes have not caused	CMMI
unintended effects on the baselines
28	Record changes to configuration	MDR and	Med
items and the reasons for the	CMMI
changes as appropriate
Table 4 summaries the mapping of the medical device CM standards against CMMI® specific goal 2 (SG2: ‘Track and Control Changes’). It may be observed that almost all of the subpractices of this CMMI® goal will have to be performed in order to satisfy the medical device standards (in fact eight of the nine CMMI® subpractices will have to be performed). However, in order to satisfy the objectives of the CMCM, an additional subpractice had to be added.
Table 4	Summary of CMCM specific goal 2 – Track and Control Changes

Practice	CMCM
subpractice numbers	No. of CMMI® subpractices	No. of CMMI® subpractices required to meet regulatory medical device requirements	No. of additional subpractices
required to meet regulatory medical device requirements	
Track and	19–23	4	4	1	
Control Changes					
Control	24–28	5	4	0	
Configuration					
Items					
Total		9	8	1	

4.2.1 CMCM subpractices related to tracking change requests
4.2.1.1 Level Med subpractices Tables 3 and 4 illustrate that the medical device
standards for tracking and controlling changes are very similar to that specified by
the CMMI® model. In order to adhere to the medical device standards, all of the subpractices required for the associated CMMI® practice are necessary, but not always to the same level of detail.
Traceability is particularly important for medical device companies, as they have to demonstrate this in order to achieve FDA compliance. In relation to traceability of change requests, the medical device standards specify that an audit trail should exist for each modification. This should contain details of any changes, the rationale for the changes and details as to who authorised the changes. The CMMI® guidelines for tracking change requests are more specific than those specified within the medical device standards and refer to the need to respond in a timely manner to change requests and to actually track the change requests to closure, as there is a desire to reduce the overhead of maintaining lengthy status lists (subpractice 22). It may also be noted that the IS0/IEC 12207 standard from which the SW68 standard evolved has recently published an amendment (ISO/IEC 12207, 2004) that provides a specific process for change request management.
An additional subpractice is required in order to ensure that each upgrade, bug fix or patch for OTS software is identified and evaluated, and that the evaluation is documented (subpractice 23), as this is not included in the associated CMMI® practice.
4.2.2 CMCM subpractices for controlling configuration items
4.2.2.1 Level Med subpractices As the control of configuration items is very important in terms of ensuring the integrity of medical device software, it is therefore no surprise that 4 (i.e. subpractices 24, 25, 27 and 28) of the five subpractices required for this CMMI® practice are necessary in order to adhere to the medical device standards (see Tables 3 and 4).
4.2.2.2 Level 1 subpractices The CMMI® provides more guidance in this area than the medical device standards and additionally requests that a procedure should be defined for checking-in and checking-out configuration items to ensure the integrity of the configuration items (subpractice 26).
4.3 SG 3: Establish Integrity
In order to fulfil SG3: ‘Establish Integrity’, the following specific practices have to be performed: establish CM records and perform configuration audits. Table 5 provides the complete list of the CMCM practices, subpractices and their associated capability level in relation to establishing integrity.
Table 6 summaries the mapping of the medical device CM standards against CMMI® specific goal 3 (SG3: ‘Establish Integrity’), it may now be determined that in order to satisfy medical device standards that not all of the subpractices of this CMMI® goal will have to be performed (in fact only 3 of the 12 CMMI® subpractices will have to be performed). Additionally, no additional (medical device specific) subpractices had to be added in order to satisfy the objectives of CMCM.

Table 5	CMCM subpractices for specific goal 3 – Establishing Integrity
Practice	CMCM	Subpractice	Source	CMCM
subpractice	level
number

Establish CM records

MDR	Med
and
CMMI
CMMI	1

29	Record CM actions in sufficient detail so
that the content and status of each configuration item is known and previous versions can be recovered
30	Ensure that relevant stakeholders have
access to and knowledge of the configuration items

31	Specify the latest version of the baseline	CMMI	1
32	Identify the version of the configuration	MDR	Med
items that constitute a particular baseline. and
CMMI
33	Describe the differences between	CMMI	1
successive baselines
34	Revise the status and history of the	MDR	Med
configuration item as necessary	and
CMMI
Perform	35	Assess the integrity of the baselines	CMMI	1
configuration
audits

CMMI	1

36	Confirm that the configuration records
correctly identify the configuration of the configuration items

CMMI	1
CMMI	1

37	Review the structure and integrity of the
items in the CM system
38	Confirm the completeness and
correctness of the items in the CM system

CMMI	1
CMMI	1

39	Confirm compliance with applicable CM
standards and procedures
40	Track action items from the audit to
closure

Table 6 Summary of CMCM specific goal 3 – Establish Integrity

Practice	CMCM
subpractice numbers	No. of
CMMI®
subpractices	No. of CMMI® subpractices
required to meet regulatory medical device requirements	No. of additional subpractices
required to meet regulatory medical device requirements	
Establish	29–34	6	3	0	
CM records					
Perform configuration audits	35–40	6	0	0	
Total		12	3	0	

4.3.1 CMCM subpractices related to establishing CM records
4.3.1.1 Level Med subpractices The process of establishing CM records is very important in terms of providing the traceability evidence that is required to meet the regulatory requirements associated with medical device software. Tables 5 and 6 illustrate that half of the subpractices (three out of six) required for this CMMI® practice are necessary in order to adhere to the medical device standards.
4.3.1.2 Level 1 subpractices Unlike the CMMI®, the medical device standards do not provide guidance in terms of ensuring that stakeholders have access to the status of the configuration items (subpractice 30) or require that the latest version of the baselines are specified (subpractice 31).
The medical device standards suggest that a history of the configuration items within a baseline should be available and this would therefore enable the differences between baselines to be obtained (subpractice 33) (however, there is no specific reference to a feature within the CMS that would enable only the differences between successive baselines to be displayed, obviously such a feature would streamline the process of comparing baselines).
4.3.2 CMCM subpractices for performing configuration audits
The medical device standards do not specify any subpractices that have to be performed in order to achieve regulatory compliance in relation to performing configuration audits. The associated specific practice in the CMMI® has no equivalent practice within the medical device standards. The medical device standards do not specify any need for auditing the CM processes and subpractices. Therefore, each of the CMCM subpractices listed in Table 5 are assigned a CMCM capability level of 1.

4.4 Summary of the CMCM specific practices
Table 7 provides a summary of the three specific goals within the CMCM. There are 40 specific subpractices required by CMCM. This consists of 38 CMMI® and 2 medical device specific subpractices. In order to satisfy the mandatory medical device CM requirements, 19 of these subpractices have to be adhered to (17 CMMI® and 2 medical device specific subpractices).
Table 7	Summary of the CMCM Specific Goals

Goal	CMCM	No. of
subpractices	CMMI®
subpractices

No. of CMMI® subpractices required to meet regulatory medical device requirements

No. of additional subpractices required to meet regulatory medical device requirements
SG 1	1–18	17	6	1	
SG 2	19–28	9	8	1	
SG 3	29–40	12	3	0	
Total		38	17	2	

4.5 The generic goals and practices of CM
The CMMI® identifies a number of generic goals and practices that are listed in Table 8 (refer to the CMMI® for a complete description of these goals (Chrissis et al., 2007)). At a fundamental maturity or capability level, it is only necessary to perform the specific base practices. It is interesting to note that guidelines within the medical device standards may, however, be mapped onto CMMI® generic goal 2 practices.

Table 8	CMCM generic goals and practices			
Practice	Practice number	Source	CMCM Level	
Goal: GG2: Institutionalise a Managed Process			
GP 2.1 Establish Policy	41	MDR and CMMI	Med	
GP 2.2 Plan the Process	42	MDR and CMMI	Med	
GP 2.3 Provide Resources	43	MDR and CMMI	Med	
GP 2.4 Assign Responsibility	44	MDR and CMMI	Med	
GP 2.5 Train People	45	MDR and CMMI	Med	
GP 2.6 Manage Configurations	46	CMMI	2	
GP 2.7 Identify Stakeholders	47	CMMI	2	
GP 2.8 M&C Process	48	CMMI	2	
GP 2.9 Evaluate Adherence	49	CMMI	2	
GP 2.10 Review	50	CMMI	2	
Goal: GG3: Institutionalise a Defined Process			
GP 3.1 Establish a Defined Process	51	CMMI	3	
GP 3.2 Collect Improvement	52	CMMI	3	
Information				
Goal: GG4: Institutionalise a Quantitatively Managed Process		
GP 4.1 Establish Quantitative	53	CMMI	4	
Objectives for the Process				
GP 4.2 Stabilise Subprocess	54	CMMI	4	
Performance				
Goal: GG5: Institutionalise an Optimising Process			
GP 5.1 Ensure Continuous Process	55	CMMI	5	
Improvement				
GP 5.2 Correct Root Causes of	56	CMMI	5	
Problems				

4.5 The generic goals and practices of CM
The CMMI® identifies a number of generic goals and practices that are listed in Table 8 (refer to the CMMI® for a complete description of these goals (Chrissis et al., 2007)). At a fundamental maturity or capability level, it is only necessary to perform the specific base practices. It is interesting to note that guidelines within the medical device standards may, however, be mapped onto CMMI® generic goal 2 practices.
Table 8	CMCM generic goals and practices			
Practice	Practice number	Source	CMCM Level	
Goal: GG2: Institutionalise a Managed Process			
GP 2.1 Establish Policy	41	MDR and CMMI	Med	
GP 2.2 Plan the Process	42	MDR and CMMI	Med	
GP 2.3 Provide Resources	43	MDR and CMMI	Med	
GP 2.4 Assign Responsibility	44	MDR and CMMI	Med	
GP 2.5 Train People	45	MDR and CMMI	Med	
GP 2.6 Manage Configurations	46	CMMI	2	
GP 2.7 Identify Stakeholders	47	CMMI	2	
GP 2.8 M&C Process	48	CMMI	2	
GP 2.9 Evaluate Adherence	49	CMMI	2	
GP 2.10 Review	50	CMMI	2	
Goal: GG3: Institutionalise a Defined Process			
GP 3.1 Establish a Defined Process	51	CMMI	3	
GP 3.2 Collect Improvement	52	CMMI	3	
Information				
Goal: GG4: Institutionalise a Quantitatively Managed Process		
GP 4.1 Establish Quantitative	53	CMMI	4	
Objectives for the Process				
GP 4.2 Stabilise Subprocess	54	CMMI	4	
Performance				
Goal: GG5: Institutionalise an Optimising Process			
GP 5.1 Ensure Continuous Process	55	CMMI	5	
Improvement				
GP 5.2 Correct Root Causes of	56	CMMI	5	
Problems				

The FDA standards state that each manufacturer shall establish the appropriate responsibility, authority and interrelation of all personnel who manage, perform and assess work affecting quality (this would relate to the CMMI® generic goal associated with assigning responsibility – GP 2.4). It also undertakes to ensure that all work is adequately resourced and that staff are trained (this sentence relates the CMMI® generic goals associated with providing resources and training – GP 2.3 and GP 2.5).
Additionally, the guidelines specify that a company should have a policy and a process in place for CM (GP 2.1 and GP 2.2). However, it should be acknowledged that these linkages are made at a very high level as the FDA specifies little detail other than a very generic sentence in relation to these areas, and no specific guidance as to how these subpractices may be achieved.
Table 8 illustrates the CMCM capability level assigned to each of the generic CMMI® practices. From inspecting Table 8, it is obvious that no CMMI® generic practices with the generic goals of 3, 4 and 5 have be performed in order to adhere to the guidelines with the MDR requirements for CM.
5 Conclusions
Table 9 provides a summary of the specific and generic goals within the CMCM. With respect to the SG and practices of the CM process area, it is clear that following the guidelines specified in the medical device standards will, at best, only partially meet the goals of this CMMI® process area (this would only fulfil 22 of the 54 subpractices required by the CMMI®). As might reasonably be expected, there is little guidance provided within the medical device standards in relation to the advanced practices of CM (medical device guidelines only refer to 5 of the 16 generic practices that are required by CMMI®). Since failure to perform any specific practice implies failure to meet the specific goal, with respect to CMMI®, it is clear, that the goals of CM cannot be obtained by satisfying medical device standards and guidelines during software development. But is the opposite true, can meeting the CMMI® goals for CM successfully meet FDA and SW68 guidelines? With the exception of two subpractices, performing the CMMI® specific practices for CM, it would, in general, more than meet the FDA and SW68 guidelines for this area.
The CMCM will enable software development medical device companies to adopt a CM process that will assist with regulatory medical device compliance issues and perform equally effectively in both local and distributed software development environments. 

Table 9	Summary of the CMCM specific and generic goals

Goal     CMCM
practice/ subpractices numbers	No. of CMMI® practices/ subpractices	No. of CMMI® practice/subpractices required to meet regulatory medical device requirements	No. of additional subpractices
required to meet regulatory medical device requirements	
SG 1	1–18	17	6	1	
SG 2	19–28	9	8	1	
SG 3	29–40	12	3	0	
GG2	41–50	10	5	0	
GG3	51–52	2	0	0	
GG4	53–54	2	0	0	
GG5	55–56	2	0	0	
Total		54	22	2	
Global and distributed development is now a fact of life for the majority of software companies. In this environment, ensuring quality and integrity during the development and release of software products demands major investment in appropriate CM systems. Key to this is the use of repositories which store all the artefacts, such as source code, tests, project plans and other documents created during the development process. All members of the distributed/global development team need to share configuration items created during development. Developments in CM tools have now enabled this to be implemented. Many of these tools are available as open source offerings. Tools such as Concurrent Versioning System (2007), OpenCM (2007), SVK (2007) and CruiseControl (2007) allow developers to collaborate effectively and efficiently without compromising the security of the developed products and greatly facilitate these new modes of working.
We felt that it was important to design CMCM to be tool independent, due to the wide range of CM tools which are now available. The CMCM model fully complements these new approaches to CM. By using this model, development teams can collaborate effectively under the governance and control of a clearly defined process.
Acknowledgements
This research is supported by the Science Foundation Ireland funded project, Global Software Development in Small- to Medium-Sized Enterprises (GSD for SMEs) as part of Lero – the Irish Software Engineering Research Centre (http://www.lero.ie).

References

Automotive SPICE (2005) ‘Automotive SIG, automotive SPICE process reference model’, The SPICE User Group Automotive Special Interest Group, Available at: http://www. automotivespice.com.
Cass, A., Völcker, C., Ouared, R., Dorling, A., Winzer, L. and Carranza, J.M. (2004) ‘SPICE for SPACE trials, risk analysis, and process improvement’, Software Process Improvement and Practice, Vol. 9, No. 1, pp.13–21.
Chrissis, M.B., Konrad, M. and Shrum, S. (2007) CMMI: Guidelines for Process Integration and Product Improvement, 2nd edition, Boston, USA: Addison Wesley.
Concurrent Versioning System (2007) Available at: http://www.nongnu.org/cvs/. CruiseControl (2007) Available at: http://cruisecontrol.sourceforge.net/.
European Council (1993) ‘Council directive 93/42/EEC concerning medical devices’, Available at: http://www.mdss.com/MDEV/93_42_EEC.htm.
FDA Regulations (1997) ‘Code of federal regulations 21 CFR Part 820’, Available at: http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&tpl=/ecfrbrowse/Title21/ 21cfr820_main_02.tpl.
FDA/CDRH (1999) ‘Guidance for off-the-shelf software use in medical devices’, FDA/CDRH Guidance Document, Available at: http://www.fda.gov/cdrh/ode/guidance/585.pdf.
FDA/CDRH (2002) ‘General principles of software validation’, FDA/CDRH Guidance Document, Available at: http://www.fda.gov/cdrh/comp/guidance/938.html.
FDA/CDRH (2005) ‘Guidance for the content of premarket submissions for software contained in medical devices’, FDA/CDRH Guidance Document, Available at: http://www.fda.gov/ cdrh/ode/guidance/337.pdf.
Hass, A.M.J. (2003) Configuration Management Principles and Practice, Boston, USA: Addison  Wesley.
Herbsleb, J., Carleton A., Rozum J., Siegel J. and Zubrow D. (1994) ‘Benefits of CMM-based software process improvement: initial results’, CMU/SEI-94-TR-013, Available at: http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr13.94.pdf.
ISO/IEC 12207 (1995) ‘Information technology – software lifecycle processes’, ISO/IEC 12207: 1995/Amd. 1:2002(E), Available at: http://www.iso.org/iso/en/CatalogueDetailPage. CatalogueDetail?CSNUMBER=21208.
ISO/IEC 12207 (2004) ‘Information technology – software lifecycle processes: amendment 2’, Available at: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail? CSNUMBER =21208.
ISO/IEC 15504 (2003) ‘Information technology – process assessment – part 5: an exemplar process assessment model’, ISO/IEC JTC1/SC7, International Standards Organisation, Available at: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER =3 8934.
ISPE (2001) ‘GAMP guide for validation of automated systems’, GAMP 4, Available at: http:
//www2.ispe.org/eseries/scriptcontent/orders/OrderSearchResults.cfm?contentarea=GAMP.

Mc Caffery, F., Donnelly, P., Dorling, A. and Wilkie, F.G. (2004) ‘A software process development, assessment and improvement framework for the medical device industry’, 
Proceedings of Fourth International SPICE Conference on Process Assessment and Improvement, SPICE User Group, Lisbon, Portugal, pp.100–109.
Mc Caffery, F., Donnelly, P., McFall, D. and Wilkie, F.G. (2005) ‘Software process improvement for the medical industry’, in C.D. Nugent, P.J. McCullagh, E.T. McAdams and A. Lymberis (Eds). Personalised Health Management Systems – The Integration of Innovative Sensing, Textile, Information and Communication Technologies, Vol. 117, Studies in Health Technology and Informatics, IOS Press, pp.1 17–124.
Mc Caffery, F., O’Connor, R. and Coleman, G. (2006) ‘Developing a configuration management model for use in the medical device industry’, in J. Filipe, B. Shishkov and M. Helfert (Eds.) Proceedings of International Conference on Software and Data Technologies (ICSOFT 2006), Portugal, pp.81–88.
OpenCM (2007) Available at: http://www.opencm.org/.
SVK (2007) Available at: http://svk.bestpractical.com/view/HomePage.
SW68 (2001) Medical Device Software–Software Life Cycle Processes, ANSI (American National Standard)/AAMI (Association for the Advancement of Medical Instrumentation).