Maturity Models for the Health

Tailoring Software Process Capability/ Maturity Models for the Health Domain Christiane Gresse von Wangenheim (corresponding author) Department of Informatics and Statistics - INE Federal University of Santa Catarina - UFSC 88049-200 Florianópolis - SC Brazil [email protected] Phone: +55-48-3721-9516 FAX: +55-48-3331-9516-R16 Aldo von Wangenheim Brazilian Institute for Digital Convergence - INCoD Federal University of Santa Catarina - UFSC 88049-200 Florianópolis - SC Brazil [email protected] Fergal McCaffery Dundalk Institute of Technology Regulated Software Research Group Dundalk Institute of Technology Dundalk Ireland [email protected] Jean Carlo R. Hauck Brazilian Institute for Digital Convergence - INCoD Federal University of Santa Catarina - UFSC 88049-200 Florianópolis - SC Brazil [email protected] Luigi Buglione Engineering.IT SpA [email protected]

Abstract. Web-based asynchronous store-and-forward telemedicine systems for diagnostic purposes, which enable the consultation of one (or more) distant health care professional(s) by a locally present health care professional concerning a patient‘s diagnosis and treatment can significantly improve healthcare services. Yet, developing high-quality asynchronous store-andforward telemedicine systems (ASFTSs) remains a challenge. However, there is no accepted understanding as to what are the important quality characteristics for this type of software system and/or what defines a mature software process for producing high-quality ASTFSs. Through adopting a multi-step research methodology, we define a quality model for ASFTSs indicating relevant quality characteristics and their priority for this specific type of software system based upon ISO/IEC 25010. We, then, propose an extended software process capability/maturity model based on ISO/IEC 15504 and ISO/IEC 12207 to meet these particular quality requirements. The resulting model can be used to both guide the development and the evaluation of such systems. We expect that the availability of such a customized model will facilitate the development of highquality ASFTSs, reducing related risks and improving the quality of telemedicine services. Keywords Software Process Capability/Maturity Models, Asynchronous Store-and-Forward Telemedicine Systems, ISO/IEC 15504, Software Quality, CMMI.

1

1. Introduction Telemedicine systems and services cover a broad spectrum of capabilities including acquisition, storage, presentation, and management of patient information (represented in different digital media such as video, audio, or data), and communication of this information between care facilities with the use of communications links [1]. Although, telemedicine has the potential to solve diverse problems in modern health care [2] [3], their quality remains a challenge considering their potential impact on human health [4], highlighting concern over the safety, reliability, privacy, security, efficiency and effectiveness of telemedicine technology. For instance, does a radiologist at a central medical center, receive images with the proper resolution to effectively provide a correct examination result? Are the patient’s data and information protected against access of non-authorized persons? Will there be no erroneous mix ups of examination results to patients? Given these concerns, there exists a legitimate interest in protecting the public from unsafe and untested telemedicine technologies. However, so far, there is no official telemedicine standard [1]. So, commonly the telemedicine industry uses high-level health care guidelines and technical standards developed for various technology sectors including multimedia conferencing, information technology, data communications, and security. In this context, basically, three types of guidelines can be identified: clinical, operational and technical [5]. Clinical guidelines address specific medical specialities, e.g., teleradiology or teledermatology. Operational guidelines focus on providing guidance on email communication, Internet access and videoconferencing, whereas technical guidelines cover specific aspects, such as interoperability, security, privacy, etc. Wellknown examples, include DICOM (Digital Imaging and Communications in Medicine), a standard for the transfer of radiologic images and other medical information and HL7, a standard for the electronic interchange of clinical, financial and administrative information among independent health care oriented computer systems. All these initiatives demonstrate the need for tailoring quality guidelines to the specific characteristics and needs in the telemedicine context. However, the existing guidelines and standards are still not comprehensive for the development of routine telemedicine products or services [5]. Especially software process capability/maturity models, which guide the assessment and improvement of a maturing software process for the development and maintenance of telemedicine systems and services are, basically, non-existent. And, although, there are various well-accepted generic Software Process Capability/Maturity Models (SPCMMs), including the CMMI framework [6], ISO/IEC 12207 [7], ISO/IEC 15504 [8], or ITIL [9], their application in practice often requires a customization to the specific context to be effective [10]. Therefore, a current trend is the customization of those generic process models for specific domains, including e.g., adaptations for space software SPICE4SPACE [11] or the automobile sector [12]. Yet, model customizations for the health care sector are basically non-existent [13], with the exception of the Medi SPICE initiative [14], which is working on a customization of ISO/IEC 15504 for the development of medical devices [15]. Two main challenges that face the medical device software industry are 1) how can companies find a complete repository detailing all the processes and practices that would be required to develop safe medical device software, and 2) how can medical device manufacturers and regulatory authorities select competent software suppliers that will not put the medical device manufacturer at risk as they (as the owner of the complete system i.e. manufactured device including software) will retain overall responsibility for the safety of the device. Medi SPICE is currently being developed to satisfy both these challenges and likewise there is a need to create such a customized model for the telemedicine domain. In this context, the research objective of this work is to develop a customized SPCMM for the development and maintenance of telemedicine software systems based on existing standards, such as, ISO/IEC 12207 and ISO/IEC 15504. We further focus our research in this broad field of telemedicine applications on asynchronous store-and-forward telemedicine systems for diagnostic purposes, which are implemented as web-based systems. Such systems enable the consultation of one (or more) distant health care professional(s) by a locally present health care professional concerning a patient‘s diagnosis and treatment, through using a web-based telemedicine system to bridge the spatial distance between the two (or more) participants. A tailored SPCMM for this specific context is expected to facilitate software process assessment & improvement in this specific domain as well as to contribute positively to the quality of the systems and services being developed.

2

2. Asynchronous Store-and-Forward Telemedicine Systems Telemedicine is broadly defined as the use of information technology to deliver health care services and information from one location to another, geographically separated location [16] [17]. More particularly, these services can speed up diagnosis and therapeutic care delivery for emergencies, support virtual hospitals in patients’ homes and allow primary healthcare providers in geographically dispersed locations to receive continuous assistance from specialized coordination centers. Telemedicine covers a wide range of services and applications, and, while there is much disagreement about definitions [18], telemedicine generally involves two general application purposes: clinical and non-clinical applications. Clinical applications of telemedicine can be classified as [18]: Triage, Diagnostic, Non-Surgical Treatment, Surgical Treatment, Consultation, Monitoring, Provision of specialty care, Supervision of primary care. Non-clinical purposes include medical education, research, administrative meetings. Telemedicine can be applied for diverse medical specialties, including, for example,: Home Care, Microbiology and Immunology, Cardiology, Ophthalmology, Mental Health, Pathology, Dermatology, Radiology, Emergency Room, Pediatrics, etc. [18]. The term delivery options refers to the temporal relationship between applications provided to conduct a telemedicine event. In general, these events are classified in [19] [20]: (1) synchronous (real time) and (2) asynchronous (store-and-forward) events. Information transactions that occur among two or more number of participants simultaneously are called synchronous communications, e.g., telemedicine through telephone calls or robotic surgery. It requires the presence of both parties at the same time and a communications link between them that allows a real-time interaction to take place. Video-conferencing equipment is one of the most common forms in synchronous telemedicine. There are also peripheral devices which can be attached to computers or the video-conferencing equipment which can aid in an interactive examination, such as, e.g., a tele-stethoscope. In asynchronous communications these transactions occur at different points in time [21]. Store-and-forward telemedicine involves acquiring medical data (like medical images, biosignals, etc) and then transmitting this data to a doctor or medical specialist at a convenient time for assessment offline. It does not require the presence of both parties at the same time. In this broad field of telemedicine applications, we focus our research on telediagnostic systems, particularly asynchronous store-and-forward telemedicine systems - ASFTS. Such systems serve for the asynchronous delivery of medical expertise, mainly findings reports for remotely performed examinations, by one (or more) distant health care professional(s). Telediagnostic is increasingly being used in those specialist fields of medicine, in which corresponding diagnostic findings data (mainly images) can be transmitted digitally, such as teleradiology, telecardiology, or teledermatology. For example, in the state of Santa Catarina/Brazil, a public asynchronous web-based telemedicine network called Santa Catarina State Integrated Telemedicine and Telehealth System performs store-and-forward telemedicine and findings reports delivery in the fields of: clinical laboratory analysis, radiology (MR, US, CT, SPECT, bone densitometry), endoscopy and colonoscopy, and EKG, besides asynchronous emergency assessment, mainly on trauma cases [22]. Today, the network interconnects more than 400 hospitals and primary health care facilities in 291 cities, performing, on average, 75,000 examinations/month. Asynchronous telemedicine systems are gaining increased acceptance and are becoming a preferred method, e.g., for obtaining second opinions of highly specialized physicians [23], as they do not require the simultaneous presence of doctors, required, for example, in teleconsultations via videoconference, which generally is extremely difficult as the likelihood of all physicians being available at the same time is a rarity. Acceptance rates by patients and technical healthcare staff has also been very high [24]. In addition, access to emerging telemedicine applications is an issue of great concern to remotely situated primary health care facilities. However, economic considerations and infrequent consultation sessions may make the installation of high-speed lines required to provide remote facilities with these much-needed services impossible. On the other side, asynchronous web-based systems generally require less infrastructure including lower bandwidth for the purpose of batch mode diagnosis, operating over low-data rate communication lines. A typical workflow of such asynchronous web-based diagnostic telemedicine systems is: 3

1. A patient is examined at a remote health care facility (hospital, primary health care facility, clinic, etc.) by a doctor, non-medical technical personnel or nurse. The examination is captured as an electronic file. 2. The examination and accompanying medical notes on the patient’s medical record are sent electronically to a central telemedicine server and become available for medical staff responsible for tele-diagnosis. 3. The responsible medical doctor/specialist analyses the examination and notes in order to indicate findings and stores the findings together with the examination information on the central telemedicine server. 4. The examination information and findings become available for the requesting physician and the regulating commission. 5. The requesting physician analyses the examination and findings and provides a diagnosis and continues the patient’s treatment. From a technology standpoint, telemedicine is the application of telecommunications and computer technologies that are already in use in other industries [16] [17] [25]. The technology includes the hardware, software, and communications link of the telemedicine project. The technology infrastructure is a telecommunications network with input and output devices at each connected location. An example of typical architecture of a web-based asynchronous diagnostic telemedicine system is shown in figure 1. The main difference between such systems and clientserver or peer-to-peer solutions, such as teleradiology networks based upon decentralized PACSs such as the one proposed by [26], is that the whole telemedicine network is generally built around a central server that stores all patient and healthcare team information, avoiding redundant performing of examinations and building a potential cornerstone for an electronic health record.

Fig. 1 Architecture of web-based asynchronous diagnostic telemedicine systems

3. Software Process Capability/Maturity Models Based on the basic premise that the quality of a software product and project performance is largely determined by the quality of the software process used to build it [27], organizations implement software process improvement initiatives assuming that a higher process capability will result in better project performance and product quality [28] [29]. 4

Software process improvement and assessment guided by a maturity level or a process capability profile based on a capability/maturity model is now well established in practice as a successful means for improving the software process. In this context, software process capability/maturity models (SPCMMs) are defined as models describing best practices for software life cycle processes, based on good engineering and process management principles, and a set of process attributes comprising capability/maturity aspects, suitable for the purpose of assessing and/or improving processes [30]. A SPCMM consists of a sequence of capability/maturity levels for a class of objects. It represents a targeted evolution path of these objects in the form of discrete phases (or stages). Typically, these objects are organizations, processes or people. The lowest phase represents an initial state characterizing an organization having little capabilities in the domain under consideration. In contrast, the highest phase represents a conception of total capability/maturity. Advancing on the evolution path between the two extremes involves a continuous progression regarding the object’s capabilities or maturity [31]. These models are used as an evaluative and comparative basis for process improvement and/or assessment implicitly assuming that higher process capability or organizational maturity is associated with a process or organization that is in a stronger position to achieve its objectives. SPCMMs are the basis for the definition of measures used to collect evidences in order to evaluate if a certain object reaches a specific capability/maturity level. Based on such a determination, then, improvement paths are recommended based on the successive, discrete levels of capability and/or maturity of the SPCMM. Typically, SPCMMs are represented by a two-dimensional structure: a process dimension describing “what is done” and a capability/maturity dimension, indicating “how well a process is done” (Figure 2).

Capability Levels Process Attributes Rating Scale Maturity Levels

Capability/Maturity Dimension

Measurement Framework

n . . .

SPCMM

2

ns

sio

en

1

r

he

0

Ot Proc. A

Dim

Proc. B

Proc. C

[...]

Process Dimension Process Reference Model Domain and Scope Processes with Purpose and Outcomes

Fig. 2 Dimensions of SPCMMs (adapted from [8]) The capability/maturity dimension sets the criteria that (based on an assessment framework) indicate the ability that a process or an organization has to achieve its business objectives, in relation to the service to process attributes associated with processes of each maturity level [8]. While capability refers to the specific characteristics of individual processes, maturity establishes levels of organizational evolution, characterizing stages of improvement of process implementation in the organization [6]. The process dimension defines a set of processes that an organization may perform to acquire, supply, develop, operate, evolve and support software, grouped into categories of related activities. The process dimension may be provided as in ISO/IEC 15504 by an external Process Reference Model (PRM), comprising definitions of processes in a life cycle described in terms of process purpose and outcomes, together with an architecture describing the relationships between the processes for a specific domain, e.g., through ISO/IEC 12207 for the software life cycle. To represent a set of best practices in the given software domain, SPCMMs are tailored to include relevant processes and practices that contribute to meeting the relevant requirements of quality and performance in the specific domain.

4. Quality Characteristics for Asynchronous Storeand-Forward Telemedicine Systems Aiming at the improvement of the quality of ASFTSs, a first step is to clearly define relevant quality characteristics for this kind of system. In order to systematically elicit these characteristics, 5

we adopted a multi-step research methodology based on the DUMOD process [32], including the following steps:  Context analysis of ASFTSs in terms of the service workflow, stakeholders and their conceptual representation. The analysis is based on literature and our experiences in developing and running a large-scale ASFTS - the Santa Catarina State Integrated Telemedicine and Telehealth System (STT/SC) (http://telessaude.sc.gov.br), a public telemedicine and telehealth infrastructure that is a joint initiative of the Telemedicine Laboratory of the Federal University of Santa Catarina – UFSC and the Santa Catarina State Government Health Office [33] [34].  Analysis of the state of the art regarding software quality models for ASFTSs through a systematic literature review searching for peer-reviewed articles in English published between 1990-2011 on software quality models for ASFTSs. The systematic search is complemented by ad-hoc searches amplifying the scope to quality models related to any kind of telemedicine system.  Identification of relevant quality characteristics (preliminary model). Based on the previous steps, principally on the definition as given by ISO/IEC 25000 [35], we decompose the abstract quality concept of ASFTSs into characteristics and sub-characteristics. This is done based on our experiences in defining quality models as well as on the development and running an ASFTS. In addition, we realized unstructured interviews with representative of diverse stakeholder classes in order to elicit their quality needs and expectations. In this step, the elicitation is limited to stakeholders involved in the Santa Catarina Telemedicine Project due to practical reasons.  Prioritization and validation of the quality model. The identified quality requirements are validated and prioritized by their importance through an expert panel. The expert panel has been conducted online using a questionnaire with questions to identify the importance of each of the quality (sub-)characteristics on a 4-point ordinal scale (essential, important, desirable, not relevant) with an additional option (don’t know). We invited about 400 persons worldwide involved in telemedicine, identifying them by tracking publications and/or participation in conferences, working groups, networks and suggestions of contacted experts. The survey has been run in October/November 2011 with a response rate of about 10%. The resulting software quality model focusing on quality in use and system quality indicates relevant quality characteristics for ASFTSs and their priority as presented in Table 1 [36]. Table 1 Relevant quality characteristics ranked by importance Perspective

Characteristic

Sub-characteristic(s) Essential characteristics

Quality in Use

Freedom from risk: degree to which a product or system Health and safety risk mitigation mitigates the potential risk to economic status, human life, health, or the environment

System Quality

Reliability: degree to which a system, product or component Maturity performs specified functions under specified conditions for a Availability specified period of time. Fault tolerance

System Quality

Security: degree to which a product or system protects Confidentiality information and data so that persons or other products or systems Integrity have the degree of data access appropriate to their types and Non-repudiation levels of authorization. Accountability

Recoverability

Authenticity Essential-Important characteristics System Quality

Functional suitability: degree to which a product or system Functional completeness provides functions that meet stated and implied needs when used Functional correctness under specified conditions. Functional appropriateness

Quality in Use

Satisfaction: degree to which user needs are satisfied when a Usefulness product or system is used in a specified context of use. Trust Pleasure Comfort

System Quality

Usability: degree to which a product or system can be used by Appropriateness recognizability specified users to achieve specified goals with effectiveness, Learnability

6

efficiency and satisfaction in a specified context of use.

Operability User error protection User interface aesthetics

Important characteristics Quality in Use

Context coverage: degree to which a product or system can be Context completeness used with effectiveness, efficiency, freedom from risk and Flexibility satisfaction in both specified contexts of use and in contexts beyond those initially explicitly identified.

System Quality

Performance efficiency: performance relative to the amount of Time behavior resources used under stated conditions. Resource utilization Capacity

System Quality

Compatibility: degree to which a product, system or component Co-existence can exchange information with other products, systems or Interoperability components, and/or perform its required functions, while sharing the same hardware or software environment.

System Quality

Maintainability: degree of effectiveness and efficiency with Modularity which a product or system can be modified by the intended Reusability Maintainers. Analysability

Important-Desirable characteristics

Modifiability Testability System Quality

Portability: degree of effectiveness and efficiency with which a Adaptability system, product or component can be transferred from one Installability hardware, software or other operational or usage environment to Replaceability another.

The created quality model confirms that high quality requirements are required in ASFTSs by requiring all quality aspects as proposed by ISO/IEC 25010, with most considered either essential or important. Especially the characteristics relating to safety (freedom from risk), reliability, security and functional suitability are considered essential. This indicates the importance of assuring these qualities in the development of high-quality ASFTSs to reduce related risks and contribute positively to the quality of telemedicine services. The principal contribution of the created quality model is the prioritization of quality characteristics by their importance within the specific context of ASFTSs, as within the generic standard ISO/IEC 25010 all characteristics are considered equally important.

5. Proposing a Tailored Capability/Maturity Model

Software

Process

Considering that the quality of a software system is largely determined by the quality of the software process used to build it, we propose a tailored SPCMM for the assessment and improvement of the software development and maintenance of ASFTSs (SPCMM-ASFTS) by customizing a generic SPCMM focusing on the achievement of qualities as defined by the specific quality model presented in the previous section. The model is systematically tailored through following the TRIM method [37] and the LEGO Maturity & Capability Model Approach [38], including the following steps:  Step 1 - Knowledge Identification: During this step, we characterized the specific context of ASFTSs and identified relevant product qualities (as presented in the previous section); and  Step 2 - Knowledge Specification: During this central step, we propose an initial version of the customized model based on appropriate source model(s), including structure and content specification of the model. The basis for the SPCMM-ASFTS is given by ISO/IEC 15504 [8], which provides a commonly accepted generic framework for the assessment of processes. The International Standard ISO/IEC 15504 also defines capability/maturity levels and specifies minimal requirements for appropriate process reference models. Accordingly, we adopt the two-dimensional structure of the ISO/IEC 15504, including the process and the capability/maturity dimension.

7

5.1 Process Dimension Defining a process dimension for the SPCMM-ASFTS implies identifying relevant processes that contain best practices for the development and maintenance of ASFTSs with the required quality characteristics as defined in the previous section. Yet, as ISO/IEC 15504 only defines requirements for a process reference model, a concrete PRM is external to 15504. We, therefore, base the process dimension on the software process as defined by ISO/IEC 12207:2008 as a starting point. Considering the context of this work, the international standard ISO/IEC 12207 provides an adequate base for defining a process reference model as ISO/IEC 12207:2008 Systems and software engineering -- Software life cycle processes is an international standard that provides a generic comprehensive set of life cycle processes, activities and tasks for software that are part of a larger system, and for stand-alone software products and services (Figure 2). The set of life cycle processes that is defined through ISO/IEC 12207 is directed to the development and maintenance of software systems meeting several of the quality characteristics considered relevant in the context of ASFTSs, such as, reliability, functional suitability, performance efficiency, etc. All processes as defined by ISO/IEC 12207 are selected as relevant for the SPCMM-ASFTS satisfying relevant quality characteristics. However, some of the quality characteristics identified as essential or important (security, safety, usability and portability) are not completely covered by ISO/IEC 12207. Therefore, we need to tailor the International Standard to comprehensively satisfy the specific quality requirements for ASFTSs (similar to what has occurred in Medi SPICE, Automotive SPICE and SPICE4SPACE). Tailoring typically involves the selection of relevant processes and/or the addition of relevant processes not covered by the baseline, in this case ISO/IEC 12207. In order to attend specific quality needs of ASFTSs, we have extended the process reference model given through ISO/IEC 12207 through several additional processes from other sources (Figure 3) with respect to the essential/important quality characteristics identified for this specific kind of system.

Fig.3 Tailored process dimension 5.1.1 Safety extension Meeting the specific safety requirements related to the freedom of risk of ASFTSs, the process reference model is extended by processes defined by ISO/IEC PRF TS 15504-10 Information technology -- Process assessment -- Part 10: Safety extension. The processes defined in this document are consistent with the following domain specific safety standards IEC 61508, +SAFE, A 8

Safety Extension to CMMI-DEV, V.1.2, IEC 60880, UK MoD Def Stan 00-56 and ISO 26262. Comparing the processes with ISO/IEC 12207 and the measurement framework defined in ISO/IEC 15504-2/15504-7, we identify the need to add processes for each of the processes defined in ISO/IEC PRF TS 15504-10:2011 (Table 2). Table 2. Added processes related to safety Process

Purpose

Outcomes

Safety Management

ensure that products, services and life cycle processes meet safety objectives.

Safety Engineering

ensure that safety is adequately addressed throughout all stages of the engineering processes.

Safety Qualification

assess the suitability of external resources when developing a safety-related software or system.

1) Safety principles and safety criteria are established. 2) The scope of the safety activities for the project is defined 3) Safety activities are planned and implemented covering safety engineering, supporting safety verification and validation, and independent assessment activities. 4) Tasks and resources necessary to complete the safety activities are sized and estimated. 5) Safety organization structure (responsibilities, roles, reporting channels, interfaces with other projects or OUs, …) is established 6) Safety activities are monitored, safety-related incidents are reported, analyzed, and resolved. 7) Agreement on safety policy and requirements for supplied products or services is achieved. 8) Supplier’s safety activities are monitored. 1) Hazards related to product are identified and analyzed ; 2) Hazard log is established and maintained ; 3) Safety case for the product lifecycle is established and maintained; 4) Safety requirements are defined; 5) Safety integrity requirements are defined and allocated; 6) Safety principles are applied to development processes; 7) Impacts on safety of change requests are analysed; 8) Product is validated against safety requirements; 9) Independent evaluations are performed. 1) Safety qualification strategy for external resources is developed 2) Safety qualification plan is developed and executed 3) Safety qualification documentation is written 4) Safety qualification report is produced

.

5.1.2 Security extension Security requirements are covered through an extension based on ISO/IEC 21827:2008 Systems Security Engineering Capability Maturity Model (SSE-CMM) [39]. This International Standard specifies the Systems Security Engineering – Capability Maturity Model (SSE-CMM). The SSECMM is a process reference model focused upon the requirements for implementing security in a system or series of related systems that are the information technology security (ITS) domain. Within the ITS domain, the SSE-CMM is focused on the processes used to achieve ITS, most specifically on the maturity of those processes. The SSE-CMM divides security engineering into three basic areas: risk, engineering, and assurance. At the simplest level, the risk process identifies and prioritizes dangers inherent to the developed product or system. The security engineering process works with the other engineering disciplines to determine and implement solutions to the problems presented by the dangers. Finally, the assurance process establishes confidence in the security solutions and conveys this confidence to the customers. Analyzing the correspondence of the security engineering processes with ISO/IEC 12207 as process reference model and the measurement framework as defined in ISO/IEC 15504-2, we defined the mapping of the standard ISO/IEC 21827:2008 as presented in Table 3 and identify processes that have to be added to the tailored model in order to approach security issues appropriately. Table 3. Mapping of ISO/IEC 21827:2008 processes ISO/IEC 21827:2008 Corresponding ISO/IEC Process 12207 Process(es) Systems security engineering process areas PA01 Administer Security Controls PA02 Assess Impact PA03 Assess Security

Corresponding ISO/IEC 15504 Process Attributes

Process to be added

Administer Security Controls Process Assess Impact Process Assess Security Risk

9

Risk PA04 Assess Threat PA05 Assess Vulnerability PA06 Build Assurance Argument PA07 Coordinate Security PA08 Monitor Security Posture PA09 Provide Security Input PA10 Specify Security Needs PA11 Verify and Validate Security Project and organizational practices process areas PA12 Ensure Quality 7.2.3 Software Quality Assurance Process PA13 Manage 7.2.2 Software Configuration Configuration Management Process PA14 Manage Project 6.3.4 Risk Management Risk Process PA15 Monitor and Control 6.3.2 Project Assessment Technical Effort and Control Process PA16 Plan Technical 6.3.1 Project Planning Effort Process PA17 Define Organization's Systems Engineering Process PA18 Improve Organization's Systems Engineering Process PA19 Manage Product Line Evolution PA20 Manage Systems 6.2.2 Infrastructure Engineering Support Management Process Environment PA21 Provide Ongoing 6.2.4 Human Resource Skills and Knowledge Management Process PA22 Coordinate with 6.1.1 Acquisition Process Suppliers

Process Assess Threat Process Assess Vulnerability Process Build Assurance Argument Process Coordinate Security Process Monitor Security Posture Process Provide Security Input Process Specify Security Needs Process Verify and Validate Security Process

PA 3.1 Process definition attribute PA 3.2 Process deployment attribute * To be covered by the portability extension

The processes to be added are defined accordingly to ISO/IEC 21827:2008 as presented in Table 4. Table 4. Added processes related to security Process Administer Security Controls

Assess Impact

Assess Security Risk

Assess Threat Assess Vulnerability Build Assurance Argument

Purpose ensure that the intended security for the system that was integrated into the system design is in fact achieved by the resultant system in its operational state. identify impacts that are of concern with respect to the system and to assess the likelihood of the impacts occurring. Impacts may be tangible, such as the loss of revenue or financial penalties, or intangible, such as loss of reputation or goodwill. identify, analyze and evaluate the security risks involved with relying on a system in a defined environment.

identify security threats and their properties and characteristics. identify and characterize system security vulnerabilities. convey clearly that the customer's security needs are met. An assurance argument is a set of stated assurance objectives that are supported by assurance evidence that may be derived from multiple sources and levels of

Outcomes Security controls are properly configured and used.

The security impacts of risks to the system are identified and characterized.

1) An understanding of the security risk associated with operating the system within a defined environment is achieved; and 2) risks are prioritized according to a defined methodology. Threats to the security of the system are identified and characterized. An understanding of system security vulnerabilities within a defined environment is achieved. The work products and processes clearly provide the evidence that the customer's security needs have been met.

10

Coordinate Security

abstraction. ensure that all parties are aware of and involved with security engineering activities.

Monitor Security Posture

ensure that all breaches of, attempted breaches of, or mistakes that could potentially lead to a breach of security are identified and reported. The external and internal environments are monitored for all factors that may have an impact on the security of the system.

Provide Security Input

provide system architects, designers, implementers, or users with the security information they need. This information includes security architecture, design, or implementation alternatives and security guidance.

Specify Security Needs

explicitly identify the needs related to security for the system.

Verify and Validate Security

ensure that solutions are verified and validated with respect to security. Solutions are verified against the security requirements, architecture, and design using observation, demonstration, analysis, and testing. Solutions are validated against the customer's operational security needs.

(1) All members of the project team are aware of and involved with security engineering activities to the extent necessary to perform their functions; and (2) Decisions and recommendations related to security are communicated and coordinated. (1) Both internal and external security related events are detected and tracked; (2) Incidents are responded to in accordance with policy; and (3) Changes to the operational security posture are identified and handled in accordance with the security objectives. (1) All system issues are reviewed for security implications and are resolved in accordance with security goals; (2) All members of the project team have an understanding of security so they can perform their functions; (3) The solution reflects the security input provided. A common understanding of security needs is reached between all parties, including the customer. (1) Solutions meet security requirements. (2) Solutions meet the customer's operational security needs.

5.1.3 Portability extension Furthermore, principally when considering the current trend of digital conversion also in the field of telemedicine porting applications to different kind of devices (such as cell phone, tablets etc.), we also added processes related to the Framework for Software Product Line Practice (v5.0) [40]. This addition emphasizes the need to organize the development of a set of different versions of such systems for different types of devices using product lines to enable effective and efficient management, in order to reduce cost by preventing rework. A software product line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way [40]. At its essence, fielding a product line involves core asset development and product development using the core assets, both under the aegis of technical and organizational management. Core asset development and product development from the core assets can occur in either order: new products are built from core assets, or core assets are extracted from existing products. Often, products and core assets are built in concert with each other. Mapping ISO/IEC 12207 processes to the software product line practice process areas (based on [41] [42] [43] as presented in Table 5, indicates processes already covered by ISO/IEC 12207 or ISO/IEC 15504-5 and/or through process attributes as defined by ISO/IEC 15504-2. Table 5. Mapping of SPL practice process areas

11

Software Product Line Practice Process Area

Corresponding ISO/IEC 12207 or ISO/IEC 15504 Process(es) Software Engineering Practice Areas Architecture Definition 7.1.3 Software Architectural Design Process Architecture Evaluation 7.1.3 Software Architectural Design Process Component Development 7.1.5 Software Construction Process Mining Existing Assets 7.3.2 Reuse Asset Management Process Requirements Engineering 7.1.2 Software Requirements Analysis Process Software System Integration 7.1.6 Software Integration Process Testing 7.2 Software Qualification Testing Process Understanding Relevant 7.3.1 Domain Engineering Domain Process Using Externally Available 6.1.1 Acquisition Process Software 7.1.6 Software Integration Process Technical Management Practice Areas Configuration Management 7.2.2 Software Configuration Management Process Make/Buy/Mine/Commission 6.3.3 Decision Analysis Management Process Measurement and Tracking 6.3.7 Measurement Process 6.3.2 Project Assessment and Control Process Process Discipline

Corresponding ISO/IEC 15504 Process Attribute(s)

PA 3.1 Process definition attribute PA 3.2 Process deployment attribute

Scoping Technical Planning

Scoping

6.3.1 Project Planning Process Technical Risk Management 6.3.4 Risk Management Process Tool Support 6.2.2 Infrastructure Management Process Organizational Management Practice Areas Building a Business Case 6.2.3 Project Portfolio Management Process Customer Interface 6.4.1 Stakeholder Management Requirements Definition Process 6.1.2 Supply Process Developing an Acquisition 6.1.1 Acquisition Process Strategy Funding Launching and Institutionalizing Market Analysis Operations 6.4.9 Software Operation Process Organizational Planning MAN 1. Organizational management Organizational Risk Management Structuring the Organization Technology Forecasting Training

Process to be added

Funding PA 3.2 Process deployment attribute Market Analysis

Organizational Risk Management Structuring the Organization Technology Forecasting

6.2.4 Human Resource Management Process

The following processes are added in order to completely cover the SPL practice process areas as illustrated in Table 6. 12

Table 6. Added processes related to portability Process Scoping

Funding Market Analysis

Organizational Risk Management Structuring the Organization Technology Forecasting

Purpose bound a system or set of systems by defining those behaviors or aspects that are "in" and those behaviors or aspects that are "out." define how the software development effort have to be financed systematic research and analysis of the external factors that determine the success of a product in the marketplace. It involves the gathering of business intelligence, competitive studies and assessments, market segmentation, customer plans and strategies, and the integration of this information into a cohesive business strategy and plan. manage risk at the strategic level by managing risks that transcend, or are shared across, projects. define and place placing the roles specific to SPLs into the appropriate organizational units to most effectively support the product line approach. identify and assess technologies continuously. They are assessed both for their immediate benefit and their potential future applicability

Outcomes Software Product Line Scope

Funding plan Market analysis

Organizational risk Organizational structure

A technology forecasting that covers both technologies that enable specific product features and technologies that support the engineering tasks in the development of those features.

5.1.4 Usability extension In this context, also the usability of such systems gains in importance and therefore, processes from ISO/TR 18529:2000 Ergonomics -- Ergonomics of human-system interaction [44] – Human-centered lifecycle process descriptions have been added in order to satisfy this important quality characteristic as identified in a mapping presented in Table 7. Table 7. Mapping of ISO/TR 18529:2000 processes ISO/TR 18529:2000 Process HDC.1 Ensure HCD content in system strategy HDC.2 Plan and manage the HDC process HDC.3 Specify stakeholders and organizational requirements HDC.4 Understand and specify the context of use HDC.5 Produce design solutions HDC.6 evaluate designs against requirements HDC.7 Introduce and operate the system

Corresponding ISO/IEC 12207 Process(es)

Corresponding ISO/IEC 15504 Process Attributes

Process to be added HCD strategy process

PA 2.1 Performance management attribute 6.4.1 Stakeholder Requirements Definition Process Context of use specification process HCD solution production process HCD evaluation process 6.4.9 Software Operation Process

Processes to be added based on ISO/TR 18529:2000 are defined in Table 8. Table 8. Added processes related to usability Process HCD Strategy

Purpose to establish and maintain a focus on stakeholder and user issues in each part of the organization which deals with system markets, concept, development and support.

Context of Use Specification

to identify, clarify and record the characteristics of the stakeholders, their tasks

Outcomes marketing will take account of usability, ergonomics and sociotechnical issues - systems will be targeted to meet users’ needs and expectations - planners will consider stakeholder and organization requirements in setting out systems strategy - the system will be more responsive to changes in its users (their needs, tasks, context etc.) - the enterprise will be more responsive to changes in its users - the system is less likely to be rejected by the market. - the characteristics of the intended users - the tasks the users are to perform - the organization and environment in which the system is used.

13

HCD Solution Production

HCD Evaluation

and the organizational and physical environment in which the system will operate. create potential design solutions by drawing on established state-of-the-art practice, the experience and knowledge of the participants and the results of the context of use analysis.

collect feedback on the developing design. This feedback will be collected from end users and other representative sources.

the whole socio-technical system in which any technical components operate will be considered in the design - user characteristics and needs will be taken into account in the purchasing of system components - user characteristics and needs will be taken into account in the design of the system - existing knowledge of best practice from socio-technical systems engineering, ergonomics, psychology, cognitive science and other relevant disciplines will be integrated into the system - communication between stakeholders in the system will be improved because the design decisions will be more explicit - the development team will be able to explore several design concepts before they settle on one - stakeholder and end-user feedback will be incorporated in the design early in the development process - it will be possible to evaluate several iterations of a design and alternative designs - the interface between the user and the software, hardware and organizational components of the system will be designed - user training and support will be developed. - feedback will be provided to improve the design - there will be an assessment of whether stakeholder and organizational objectives have been achieved or not - long-term use of the system will be monitored. In the case of evaluation to identify improvements to the system (formative evaluation), successful implementation of the process will reflect: - potential problems and scope for improvements in: the technology, supporting material, organizational or physical environment and the training - which design option best fits the functional and user requirements - feedback and further requirements from the users. In the case of evaluation to assess whether objectives have been met (summative evaluation), successful implementation of the process will demonstrate: - how well the system meets its organizational goals - that a particular design meets the human-centered requirements - conformity to international, national and/or statutory requirements.

5.1.5 Process addition in accordance to ISO/IEC 15504 Completing system and software life cycle processes, two processes as defined by the exemplar process reference model in ISO/IEC15504-5:2006 are added, which are not covered directly by ISO/IEC 12207 in order to be able to define a 15504-conformant assessment model using the tailored process dimension.

5.2 Capability/Maturity Dimension The measurement framework of SPCMM-ASFTSs is based on a continuous representation following ISO/IEC 15504-2, therefore defining capability levels and in the case of a staged representation based on ISO/IEC 15504-7 defining maturity levels. 5.2.1 Capability Levels Based on ISO/IEC 15504-2, process capability is defined on a six point ordinal scale that enables capability to be assessed from the bottom of the scale “Incomplete” through to the top end of the scale “Optimizing”. The scale represents increasing capability of the implemented process, from not achieving the process purpose through to meeting current and projected business goals. Within this measurement framework, the measure of capability is based upon a set of Process Attributes (PA). Each attribute defines a particular aspect of process capability. The extent of 14

process attribute achievement is characterized on a defined rating scale. The combination of process attribute achievement and a defined grouping of process attributes together determine the process capability level (Table 9). Table 9 Definition of capability levels (ISO/IEC, 2003) Capability Level 0. Incomplete process 1. Performed process 2. Managed process

3. Established process

4. Predictable process 5. Optimizing process

Definition The process is not implemented, or fails to achieve its process purpose. The implemented process achieves its process purpose. The Performed process is now implemented in a managed fashion (planned, monitored and adjusted) and its work products are appropriately established, controlled and maintained. The Managed process is now implemented using a defined process is capable of achieving its process outcomes The Established process now operates within defined limits to achieve its process outcomes. The Predictable process is continuously improved to meet relevant current and projected business goals.

Process Attribute(s) -PA 1.1 Process performance PA 2.1 Performance management PA 2.2 Work product management

PA 3.1 Process definition PA 3.2 Process deployment PA 4.1 Process measurement PA 4.2 Process control PA 5.1 Process innovation PA 5.2 Process optimization

Here, we adopt the definition of capability levels from ISO/IEC 15504-2 “as is”, as the process capability is not expected to change in the context of ASFTSs. 5.2.2 Organizational Maturity Levels As defined ISO/IEC 15504-7, Organizational Maturity is an expression of the extent to which an organization consistently implements processes within a defined scope that contributes to the achievement of its business goals (current or projected). Organizational maturity is defined on a six point ordinal scale that enables maturity to be assessed from the bottom of the scale “Level 0 Organization - the Immature Organization”, through to the top end of the scale “Level 5 Organization - the Innovating Organization” (Table 10). The scale represents the extent to which the organization has explicitly and consistently performed, managed and established it processes with predicable performance and demonstrated the ability to change and adapt the performance of the processes fundamental to achieving the organization’s business goals. Table 10 Definition of organization maturity levels [8] Organization Maturity Level

Definition

0. Immature

The organization does not demonstrate effective implementation of its processes that are fundamental to support the organization’s business. The organization demonstrates achievement of the purpose of the processes that are fundamental to support the organization’s business. The organization demonstrates management of the processes that are fundamental to support the organization’s business. The organization demonstrates effective definition and deployment of the processes that are fundamental to support the organization’s business. The organization demonstrates a quantitative understanding of relevant processes that are fundamental to support the organization’s business goals, in order to establish consistent and predictable performance. The organization demonstrates the ability to change and adapt the performance of the processes that are fundamental to support the organization’s business goals in a systematically planned and predictable manner.

1. Basic 2. Managed 3. Established 4. Predictable

5. Innovating

15

Following ISO/IEC 15504-7, processes can be categorized into 5 sets based on their contributions to the business goals of the organization. The set of fundamental processes that support the business is called the basic process set. Each organizational maturity level beyond level 1 maturity is characterized by the implementation, at an appropriate level of process capability, through a further set of processes that drive the achievement of the capabilities relevant to each maturity level. These are called extended process sets. As a starting point, we draw the definition of the basic and extended process sets from Appendix A of ISO/IEC 15504-7, which defines an exemplar organizational maturity model designed for organizations in the software industry. Based on the identified quality model (as presented in the previous section), further processes (not covered by the organizational maturity model as defined in 15504-7) are added to the sets in relation to their identified priority as illustrated in Table 11. Table 11. Processes associated to Maturity Levels Set

ML

Processes

Source

Basic process set

1

Stakeholder Requirements Definition System Requirements Analysis System Architectural Design Software Requirements Analysis Software Architectural Design Software Detailed Design Software Construction Software Integration Software Quality Assurance Software Verification Software Validation Software Review Software Audit Software Qualification Testing System Integration System Qualification Testing Software Installation Software Acceptance Support Software Maintenance (Security) Administer Security Controls (Security) Assess Threat (Security) Monitor Security Posture (Security) Provide Security Input (Security) Specify Security Needs (Security) Verify and Validate Security

ISO/IEC 12207:2008

(Safety) Safety Engineering

ISO/IEC PRF TS 15504-10

(Usability) Context of Use Specification (Usability) HCD Solution Production (Usability) HCD Evaluation Software Documentation Management Software Configuration Management Software Problem Resolution Management Project Planning Project Assessment and Control Risk Management Information Management Acquisition Supply

ISO/TR 18529:2000

Extended Process Sets

2

3

ISO/IEC 21827:2008

ISO/IEC 12207:2008

Change Request Management

ISO/IEC 15504-5:2006

(Safety) Safety Management (Security) Coordinate Security Project Portfolio Management Human Resource Management Infrastructure Management Life Cycle Model Management Quality Management Measurement Reuse Asset Management Reuse Program Management Domain Engineering

ISO/IEC PRF TS 15504-10 ISO/IEC 21827:2008 ISO/IEC 12207:2008

16

Organizational Management

ISO/IEC 15504-5:2006

(Safety) Safety Qualification

ISO/IEC PRF TS 15504-10

(Security) Assess Impact (Security) Assess Security Risk (Security) Build Assurance Argument (Security) Assess Vulnerability (Usability) HCD strategy

ISO/IEC 21827:2008

(Portability) Scoping (Portability) Funding (Portability) Market Analysis (Portability) Organizational Risk Management (Portability) Structuring the Organization (Portability) Technology Forecasting

A Framework for Software Product Line Practice

4

N/A

N/A

5

N/A

N/A

ISO/TR 18529:2000

6. Conclusions Based on identified quality characteristics and their degree of importance for ASFTS, we propose a software process capability/maturity model for the development and maintenance of ASFTSs. The SPCMM-ASFTS is based on ISO/IEC 15504 and its process dimension is developed by extending ISO/IEC 12207 through several processes related to quality characteristics considered essential and/or important in the context of ASFTSs. Our next steps are to validate the proposed SPCMM through an international expert panel and to accompany its application in practice. As such, this innovative SPCMM for this kind of software system has the potential to guide the development and evaluation of high-quality ASFTSs by indicating and prioritizing relevant nonfunctional requirements as well as indicating processes relevant to mature the development of ASFTSs. This work is a step forward to provide a better understanding of the development of ASFTSs potentially contributing to the improvement of the quality of such systems as a basis for an improvement of telemedicine services. Acknowledgements We would like to thank all experts who participated in the interviews and/or survey for their valuable input to our research. We would also like to thank Adriano Borgatto for his support during data analysis. This work has been supported by the CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico – www.cnpq.br), an entity of the Brazilian government focused on scientific and technological development, the MCT (Ministério da Ciência e Tecnologia)/FINEP (Financiadora de Estudos e Projetos) and FAPESC (Fundação de Amparo à Pesquisa e Inovação do Estado de Santa Catarina). This research is supported in part by the Science Foundation Ireland (SFI) Stokes Lectureship Programme, grant number 07/SK/I1299, the SFI Principal Investigator Programme, grant number 08/IN.1/I2030 (the funding of this project was awarded by Science Foundation Ireland under a cofunding initiative by the Irish Government and European Regional Development Fund), and supported in part by Lero (http://www.lero.ie) grant 03/CE2/I303_1.

References 1.

ISO (2004) TR 16056-1:2004 Health informatics – Interoperability of Telehealth Systems and Networks. Part 1: Introductions and definitions. Int’l Organization for Standardization.

2.

Bashshur, R. L. (1997) Telemedicine and the Health Care System in Telemedicine - Theory and Practice, R.L. Bashshur, J.H. Sanders, and G.W. Shannon (eds.), Charles C. Thomas, Springfield, IL.

3.

U.S. Congress, Office of Technology Assessment. (1995) Bringing Health Care Online: The Role of Information Technologies. Office of Technology Assessment. U.S. Congress, Ed.: U.S. Government Printing Office. Available at: http://www.fas.org/ota/reports/9507.pdf 17

4.

LeRouge, C. et al. (2004) Telemedicine Encounter Quality: Comparing Patient and Provider Perspectives of a Socio-Technical System. Proc.of the 37th Hawaii International Conference on System Sciences, Hawaii/USA.

5.

Loane, M.; Wootton, R. (2002) A review of guidelines and standards for telemedicine. Journal of Telemedicine and Telecare, 8(2), pp. 63-71.

6.

CMMI Product Team. (2010) CMMI for Development (CMMI-DEV), Version 1.3. Technical Report CMU/SEI-2010-TR-033, Carnegie Mellon University/ Software Engineering Institute, Pittsburgh/USA.

7.

ISO/IEC (2008) 12207:2008, Information technology - Software life cycle processes. Int’l Organization for Standardization.

8.

ISO/IEC (2003) 15504:2003-2008, Information technology - Software process assessment. Int’l Organization for Standardization. Part 1 – Part 7, 2003 to 2008.

9.

ITIL (2011). ITIL v3 Refresh. Available at: http:// www.itil-officialsite.com.

10. Beecham, S.; Hall, T.; Rainer, A. (2005) Defining a Requirements Process Improvement Model. Software Quality Journal, 13(3), pp. 247-249. 11. Cass, A. et al. (2004) SPICE for SPACE Trials, Risk Analysis, and Process Improvement. Software Process: Improvement and Practice, 9(1). 12. Spice User Group. (2012) Automotive SPICE® Process Reference Model v4.5. Technical Report. Available at: Access on: February/2012. 13. Gresse von Wangenheim, C.; Hauck, J. C. R.; Salviano, C. F.; Wangenheim, A. (2010) Systematic Literature Review of Software Process Capability/Maturity Models. Proc. of 10th International Conference on Software Process. Improvement And Capability dEtermination (SPICE), Pisa/Italy. 14. McCaffery, F.; Dorling, A. (2010) Medi SPICE Development. Software Process Maintenance and Evolution: Improvement and Practice Journal, 22(4), pp. 255-268. 15. McCaffery, F.; Richardson, I. (2007) MediSPI: A Software Process Improvement Model for the medical device industry based upon ISO/IEC 15504. Proc. of International SPICE Days 2007, Germany. 16. U.S. General Accounting Office (1997) Telemedicine: Federal Strategy is Needed to Guide Investments. Washington, DC: U.S. Senate. 17. Institute of Medicine (1996) Telemedicine: A Guide to Assessing Telecommunications in Health Care, National Academy Press, Washington, DC, 1996. 18. Tulu, B. Chatterjee, S. Laxminarayan, S. (2005) A Taxonomy of Telemedicine Efforts with respect to Applications, Infrastructure, Delivery Tools, Type of Setting and Purpose. Proceedings of the 38th Hawaii International Conference on System Sciences, Island of Hawaii, 2005. 19. Maheu, M. M., Whitten, P. and A. Allen (2001) E-Health, Telehealth, and Telemedicine: A Guide to Start-Up and Success, First ed. San Francisco: Jossey-Bass Inc., 2001. 20. Coiera, E. (1997) Guide to Medical Informatics, The Internet and Telemedicine, First ed. London,UK: Chapman & Hall, 1997. 21. Glueckauf, R. L., Whitton, J. D. and Nickelson, D. W. (2002) Telehealth: The New Frontier in Rehabilitation and Health Care, in Assistive Technology: Matching Device and Consumer for Successful Rehabilitation, M. J. Scherer, Ed., 1st ed. Washington D.C.: Amarican Psychological Association, 2002. 22. Maia, R. S., Wangenheim, A. von, Nobre, L. F. (2006) A Statewide Telemedicine Network for Public Health in Brazil. In Proc. of 19th IEEE Symposium on Computer Based Medical Systems - CBMS2006, Salt Lake City, 2006. 23. EHTEL - European Health Telematics Association (2008) Sustainable Telemedicine: Paradigms for future-proof healthcare - A Briefing Paper. Version 1.0, 20 February 2008. 24. von Wangenheim, A. ; Nobre, L. F. S. ; Tognoli, H. ; Nassar, S.M. ; HO, K. (2012) User Satisfaction with Asynchronous Telemedicine A Study of Users of Santa Catarina s System of Telemedicine and Telehealth. Telemedicine Journal and e-Health, v. 18, p. 339-346, 2012. 25. Perednia D. A., Allen, A. (1995) Telemedicine technology and clinical applications. J. Amer. Med. Assoc., vol. 273, no. 6, pp. 483–488, 1995. 18

26. Staemmler M, Walz M, Weisser G, Engelmann U, Weininger R, Ernstberger A, Sturm J. Establishing End-to-End Security in a Nationwide Network for Telecooperation. In: Mantas J et al (Eds). Quality of Life through Quality of Information. Proceedings of MIE2012. Amsterdam: IOS Press (2012) 512-516. 27. Paulk, M.C. (2009) A History of the Capability Maturity Model for Software, ASQ Software Quality Professional, 12(1), pp. 5-19. 28. Jung, H. W.; Goldenson, D. R. (2009) Evaluating the relationship between process improvement and schedule deviation in software maintenance. Journal Information and Software Technology, 51(2), pp. 351-361. 29. Fuggetta, A. (2000) Software process: A Roadmap. Proc. of the 22nd International Conference on Software Engineering, Limerick/Ireland, pp. 25-34. 30. Salviano, C. F.; Figueiredo, A. (2008) Unified Basic Concepts for Process Capability Models. Proc. of 20th Int. Conference on Software Engineering and Knowledge Engineering (SEKE), San Francisco/USA, pp. 173-178. 31. Becker, J.; Knackstedt, R.; Pöppelbuß, J. (2009) Developing Maturity Models for IT Management - A Procedure Model and its Application. Journal Business & Information Systems Engineering, 1(3). 32. Villalba, M. T.; Fernandez-Sanz, L.; Martınez, J. J. (2010) Empirical support for the generation of domain-oriented quality models. Journal IET Software, 4(1), pp. 1-14. 33. Wallauer J.; Macedo D.; Andrade R.; von Wangenheim A. (2008) Creating a Statewide Public Health Record starting from a Telemedicine Network. IT Professional, 10, pp. 12-17. 34. von Wangenheim A.; Barcellos C.L.; Wagner H. M.; Gomes C. C. (2009) Ways to implement large scale telemedicine: The Santa Catarina Experience. Latin-American Journal of Telehealth, 3, pp. 364-376. 35. ISO/IEC (2011) 25010:2011 Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models. Int’l Organization for Standardization. 36. Gresse von Wangenheim, C.; von Wangenheim, A. (2011) A Software Quality Model for Asynchronous Store-and-Forward Telemedicine Systems. Technical Report INCoD/UFSC 005/2011 - E – GQS, GQS/INCoD/UFSC, Florianópolis/Brazil. Available at: http://www.incod.ufsc.br/a-software-quality-model-for-asynchronous-store-and-forwardtelemedicine-systems/ 37. Hauck, J. C. R.; Gresse von Wangenheim, C.; McCaffery, F.; Buglione, L. (2011) Proposing an ISO/IEC 15504-2 Compliant Method for Process Capability/Maturity Models Customization. Proc. of the 12th International Conference on Product Focused Software (PROFES), Torre Canne/Italy. 38. Buglione, L.; Gresse von Wangenheim, C.; Hauck, J. C. R.; McCaffery, F. (2011) The LEGO Maturity & Capability Model Approach. Proc. of the 5th World Congress on Software Quality, Shanghai/China. 39. ISO/IEC (2008) 21827:2008 – Information Technology – Security techniques - Systems Security Engineering - Capability Maturity Model (SSE-CMM). 40. Northrop, L.M.; Clements, P. C. (2007) A Framework for Software Product Line Practice, Version 5.0. SEI, July, Available at: http://www.sei.cmu.edu/productlines/frame_report. 41. Jones, L. G., Soule, A. L. (2002) Software Process Improvement and Product Line Practice: CMMI and the Framework for Software Product Line Practice, Technical Note CMU/SEI2002-TN-012, July 2002. 42. Stallinger F., Neumann R., Schossleitner R., Zeilinger R. (2011) Linking Software Life Cycle Activities with Product Strategy and Economics: Extending ISO/IEC 12207 with Product Management Best Practices. Proc. of the International Conference SPICE , Limerick/Irleland, 2011 43. Hoyer C., Chroust G. (2006) Evolving Standard Process Reference Models for Product Line Development. Proc. of Conference on Software Engineering and Advanced Applications, Dubrovnik, Croatia, 2006 44. ISO (2000) 18529:2000 Ergonomics -- Ergonomics of human-system interaction – Humancentred lifecycle process descriptions. Int’l Organization for Standardization. 19

20