MPS systems often use VR technologies. Thus, MPS systems involve resource-consuming computations because VR environments should allow human users to interact in real time with a computer-simulated environment (Kim, 2005). Advanced interaction techniques are used because MPS systems do not only integrate visual information, but also information pertinent to the sense of touch of human tissues and organs (Sorid and Moore, 2000). Thus, many MPS systems integrate complex haptic hardware systems for user-software interaction (e.g., to simulate the use of an endoscopic tool inside a human body). This is in contrast to ordinary software systems that use mouse, keyboard, or touchpads as input devices, and monitors, screens, or visual displays as output devices.

11.2.2 Software development for MPS systems

Developing MPS systems requires knowledge in many different areas, such as sensing and tracking technologies, stereoscopic displays, or multimodal interaction (Kim, 2005). Usually, MPS systems involve small teams and small- to medium-scale software. Close communication between users and developers of the software is essential for timely delivery of the working software. In the following paragraphs we outline some existing work on software development for MPS systems, without focusing on architecture or design activities.

• Troyer et al. (2007) applied conceptual modeling as commonly used in software engineering to the engineering of VR systems. The main goal was to reduce the complexity of VR applications by narrowing the gap between the application domain (i.e., MPS systems) and the level at which VR applications are specified by software designers. Conceptual modeling claims to involve customers in the design process of VR applications and to detect design flaws early on.

• VRID, an approach for developing VR interfaces, has been proposed by Tanriverdi and Jacob (2001). VRID divides the design process of VR systems into a low-level and a high-level phase and formally represents the environment of VR applications: It separates graphics from interaction and application data. In this sense, VRID utilizes ideas from the Model-View-Controller pattern.

• The CLEVR approach (Kim et al., 1998; Seo and Kim, 2002) utilizes UML and object-oriented design for designing VR applications. CLEVR uses simultaneous functional and behavioral modeling, hierarchical modeling and top-down creation of levels of detail, incremental execution and performance tuning, user task and interaction modeling, and compositional reuse of virtual objects.

• Geiger et al. (2000) presented an approach for developing animated and interactive media, whereas Willans and Harrison (2001) developed a toolset to separate designing interaction techniques from building a specific virtual world. Both works focus on aspects related to visualizations.

• A higher-level software engineering concept for VR has been presented by Seo, who proposed a spiral model for VR system development (Seo and Kim, 2002). This model can be viewed as a classical spiral software engineering process with requirements analysis as stage 0, system architecture “scene” modeling as stage 1, refinement as stage 2, and the development of presence and special effects as stage 3. This spiral model does not cover testing; however, some performance tuning and system simulation and validation is included.

• Focusing more on requirements-related aspects, Kim (2005) presented a requirements engineering perspective on the development of VR systems. Different levels of requirements are defined, with an internal view, interaction, and models as well as simulation parts of VR applications. The approach uses storyboards (visual scripts with informal sketches and annotations) to document requirements. These requirements are refined in UML class diagrams. UML message sequence diagrams are used to describe interactions within a VR system. Similarly, in our previous work we explored a requirements-centric perspective on the design of VR applications, following an agile-inspired approach (Galster and Widmer, 2010).

Kim, 2005 describes three factors that make the development of VR software different from other software systems:

1. Real-time performance requirements, while maintaining an acceptable level of realism and presence of virtual objects in a virtual space.

2. Modeling the appearance of objects and physical properties, including functions and behavior.

3. Consideration of different styles and modalities of interaction, according to different tasks and I/O devices.

Consequently, many system goals and drivers have to be considered simultaneously during architecting, some of which are conflicting (e.g., technology choices about I/O devices and physical properties of virtual objects). However, due to their innovative nature, most MPS systems are often developed following ad hoc practices or practices that are more similar to developing scientific software (Sanders and Kelly, 2008). For example, similar to scientific software development, MPS systems typically involve scientists knowledgeable in the application domain.

11.2.3 Quality attributes of MPS

No comprehensive study on quality attributes for MPS systems exists. However, quality attributes have been studied in the medical domain in general. For example, Wijnstra (2001) identified important quality attributes for medical imaging product lines: reliability, safety, functionality, portability, modifiability, testability, and serviceability. These quality attributes may also appear in MPS systems. As we will show later, functionality as a quality attribute (in terms of model correctness) also appears in MPS systems. Capilla and Martinez (2004) explore software architecture for VR applications and propose an architecture. However, their approach does not consider qualities such as performance, usability, and presence.

11.4.1 Performance

Performance is crucial for MPS systems. Most, if not all, MPS systems are real-time applications. For medical practitioners and end-user representatives, performance refers to the smoothness of rendering objects and interaction. Usually, several performance goals for one stakeholder exist (measured in terms of response time, frame rate, etc.). Given that efficiency in ISO 9126 defines the capability of a software product to provide appropriate performance relative to the amount of resources used, we define performance as a subcategory of efficiency in ISO 9126 (ISO/IEC/IEEE, 2011).

11.4.2 Usability

Usability refers to the ease of use of an MPS system. MPS systems should be usable in an intuitive manner, and interaction with virtual objects should happen just like in a real-world setting. In ISO 9126, usability refers to the capability of a software product to be understood, learned, used, as well as its ability to attract users (ISO/IEC/IEEE, 2011). Furthermore, ISO 9126 defines understandability, learnability, and operability as a subcategory of usability. Thus, we also define usability in MPS systems as a subcategory of quality. Usability can be determined and measured using soft methods (e.g., usability tests that include test users) or hard metrics (e.g., time to learn how to use an application or the number of errors made by a novice user) (Kotonya and Sommerville, 1998). In particular, understandability and interpretability of visualizations of virtual organs are a crucial quality attribute requirement of medical examiners. Note that performance and usability affect each other. Despite being defined as similar in ISO 9126, performance is not classified as usability in our work.

11.4.3 Model correctness

ISO 9126 defines functionality as the capability of a software product to provide functions that meet stated and implied needs when the software is used under specified conditions. More specifically, ISO 9126 defines accuracy as the capability of a software product to provide the right or agreed results or effects with the needed degree of precision (ISO/IEC/IEEE, 2011). Thus, we define model correctness as a subcategory of functionality. Most, if not all, MPS systems use physical and mathematical models to represent real-world phenomena (such as human tissue). Such models are usually not understood by software architects and designers, but require the involvement of domain experts, such as physicists and biomedical engineers. The correctness and accuracy of those models is crucial for the applicability and reliability of an MPS system. For example, measurements obtained from mathematical models must be accurate enough to provide realistic simulations of human tissue for informed surgery planning. The meaning of “accurate enough” is usually determined by closely involving medical domain experts in the definition of quality attribute requirements.

We found that these three quality attributes describe requirements that are architecturally significant (Chen et al., 2013). According to Chen et al., a requirement or quality attribute is “architecturally significant” if it meets the following criteria:

• Has wide impact: Many different stakeholders; components are affected by performance, usability, and model correctness.

• Targets trade-offs: Trade-offs occur because no solution satisfies all requirements equally well. For example, it is usually not possible to achieve good performance and high model accuracy.

• Implies strictness: Usually, performance, usability, and model correctness are not negotiable. This means that when making architectural decisions, the quality attributes that can be satisfied by multiple design options will allow flexibility in architectural design, whereas strict requirements determine architectural decisions because they cannot be satisfied by alternative design options (Chen et al., 2013).

• Is difficult to achieve: Performance, usability, and model correctness are difficult to meet and technologically challenging.

There may be other quality attributes in the context of MPS systems (e.g., robustness, portability between different operating systems). However, we found the three quality attributes mentioned above to be the ones that appear in most MPS systems and across all projects. For example, portability may only occur in projects that develop product lines of MPS systems, and robustness tends to be of lower importance in MPS systems used for training surgeons (i.e., it would not be treated as a key driver). Consequently, these three quality attributes tend to drive trade-off analyses. Furthermore, we found them as key concerns for determining the success of an MPS system projects (e.g., to derive test cases).

Qualities that are closer to the architecture (or “intrinsic” qualities, such as maintainability, extendibility) are just as important as in other projects. However, we found them to be addressed implicitly throughout design and not considered as architectural key drivers.

11.5.1 Architectural stakeholders

We found that the architect and the end-user representative (surgeon, medical examiner, etc.) are the most important stakeholders. In contrast to other types of software, the main duty of the architect is usually to have a clear understanding about the technologies used in the project, rather than to have a clear understanding about the scope and main drivers of the system. This is because many architectural decisions in the context of MPS systems are technological decisions. The architect would, for example, rely on input from 3D artists.

Furthermore, in contrast to large-scale software projects that often follow disciplined processes with clearly defined roles, architects usually reside at a client side and interact with customers closely for prioritizing user stories. These user stories are extracted from medical examiners. Patients are usually not directly involved in the development process of MPS systems. Their concerns are mostly represented by regulatory bodies. Regulatory bodies, such as standardization organizations or government agencies only have limited interests in the architecture. However, regulatory bodies have a strong interest in certifying MPS systems. For this purpose the architecture description document provides a useful source of relevant information. Other stakeholders, such as testers and product owners, make an appearance, but they do not have significant impact on architectural concerns.

11.5.2 MPS architecture documentation

The development process in the context of MPS systems often follows agile and heavily incremental and iterative procedures. As found in a previous study (Falessi et al., 2010), the software architecture in an agile context aims at facilitating communication among organizations involved in the development, production, fielding, operation, and maintenance of a system. The same applies for the architecture for medical simulation and planning systems. On the other hand, the architecture document of MPS systems was found less useful for supporting system planning and budgeting activities. When certifying MPS systems, the architecture document may play a significant role as a form of system documentation. This means that architecture documentation is a deliverable required by certification bodies.

As found by Babar (2009), several changes occur in software architecture documentation practices that apply agile approaches. In particular, the level of details of architecture documentation is lower compared to non-agile approaches. Also, formal architecture documentation was considered as not adding much value in MPS projects. Thus, we recommend only documenting the most important aspects for the most important stakeholders in an architecture description document. To support documenting important concerns for certain stakeholders, we recommend using architecture viewpoints and views. These help document important concerns of different stakeholders at different stages of the development process (ISO/IEC/IEEE, 2011).

11.5.3 Architecture process

Architecting in the context of MPS systems is inspired by agile development practices. For example, XP and agile practices seems to be well-suited for innovative and creative software development (Conforto and Amaral, 2008; Highsmith, 2004; Johnston and Johnson, 2003), the regulated life science industry (Fitzgerald et al., 2013) and regulated and complex industries in general (such as the automotive or aerospace domain) (Cawley et al., 2010). In this sense, MPS systems benefit from an agile architecture. In the following, we relate MPS software systems architecting to generic architecture design activities as proposed by Hofmeister et al. (2007):

• Architecture analysis: Architecture analysis defines the problem that a system architecture must solve. During architecture analysis, architectural concerns and the context of the system are examined to define a set of architecturally significant requirements. When developing MPS systems, architecturally significant requirements include requirements identified based on the quality attributes described before. In addition, project-specific key drivers can be identified (e.g., information security). Furthermore, concerns are derived from questions related to these quality attribute requirements that we would expect an architecture description document to help answer (see concerns listed in Table 11.1). Architecture analysis usually involves the architect(s) and domain experts (such as physicists) and medical examiners.

• Architecture synthesis: Architecture synthesis proposes architecture solutions (e.g., architecture candidates or decision alternatives). Architecture solutions or decision alternatives must accommodate architecturally significant requirements that were identified during architecture analysis. Common decision alternatives that occur in the context of MPS systems include what kind of programming language to use (scripting languages that do not require detailed understanding of VR concepts or lower-level programming languages), what kind of libraries to use to render graphics (OpenGL, etc.), or what authoring tools to use to develop a static scene in the world in which objects are located, including lings, viewpoints, cameras. Because the required expertise in VR and computer graphics varies significantly between these alternatives, the skills and knowledge of developers are the main decision criteria for these architectural decisions.

• Architecture evaluation: Architecture evaluation examines candidate architectural decisions against the architecturally significant requirements. Based on the outcome of the evaluation, the architecture can be revised by going back to architecture analysis and/or synthesis. Usually, architecture evaluation is done based on continuous testing rather than following strict architecture or design reviews (see below). Architecture evaluation is one of the most crucial aspects for successful MPS systems. To address the three key concerns of performance, usability, and model correctness, continuous testing was found to be useful. Here, the architecture description must support continuous testing. Furthermore, we recommend the definition of architecture viewpoints (ISO/IEC/IEEE, 2011) to provide models and other forms of description that help represent performance, usability, and correctness concerns. As shown in our previous work (Widmer and Hu, 2011), using Finite Element Method (FEM) models helped compare different implementation choices of physical models. These models could become part of an architecture view to describe the runtime behavior of a physical model used in a MPS system. This is similar to using execution viewpoints in the context of architecting MRI systems, as proposed by Arias et al. (2011). To further facilitate architecture evaluation, an approach similar to Active Reviews for Intermediate Designs (Clements, 2000) could be applied. The benefit of such approach would be that architecture evaluation could start very early in the architectural design process to ensure that the architecture of MPS is tenable. Reviews could be done before completely building a system first. Furthermore, such reviews would also ensure that the most important stakeholders are engaged early in the software development project. Early designs, or in the case of MPS also late designs, are often poorly documented and described and lack important details that would allow a proper assessment with regard to the most important architectural key drivers. Nevertheless, early reviews could already detect problems at early stages. Based on Clements (2000), we envision the following review steps:

1. Identify the most important stakeholders. These stakeholders are most likely the stakeholders listed in Table 11.1.

2. Prepare a briefing of stakeholders. This briefing should include an explanation of the most important quality attributes (such as performance, usability, and model correctness). Model correctness may not be checked through qualitative reviews, but through more formal approaches, such as model checking or testing (as explained before).

3. Identify scenarios for performance and usability. These scenarios can be used throughout the qualitative review. In Figure 11.2 we included some quality attribute requirements that could be used as starting points for scenarios to evaluate the architecture of MPS systems. Note that we do not identify scenarios for model correctness because correctness is usually checked through quantitative testing approaches.

In contrast to conventional reviews, such “active” reviews would require evaluators and reviewers to be more actively engaged in the review, rather than merely checking whether the architecture complies with certain criteria. For example, reviewers could be asked to write down exceptions for unexpected behavior of physical tissue or feedback provided through a haptic device that could occur within an MPS system, rather than simply checking whether exceptions have been defined during architecting. Exceptions written down by reviewers could then be compared with exceptions captured in the architecture.

The initial effort for architecture evaluation may be significant, but decreases with iterations. This is because in each iteration the architecture is refined. Thus, it is not required to evaluate each aspect of the architecture in each iteration. Furthermore, testing time is reduced because many problems that may occur during testing have been identified during architecture analysis.

Tang et al. (2010) also consider architecture implementation and architecture maintenance. Here, architecture implementation is about realizing the architecture by defining a detailed design (such as designing concrete algorithms to be used to simulate human tissue) and implementing a system by coding the application. Architecture maintenance is about accommodating changes once the initial system has been deployed. As argued before, MPS systems are often developed in an agile manner. Thus, we do not separate these two activities from the other activities introduced above, but rather consider them as integrated with architecture synthesis and evaluation.

During architecture maintenance and incremental synthesis, architecture refactoring is a key practice to improve or adjust the architecture to quality attribute requirements related to the three core quality attributes mentioned above. Refactoring is particularly useful to achieve performance improvements in physical models. Potential improvements are identified through reviews.

Another practice that was found useful in the context of architecting is simple design. Simple design keeps development at a low level of complexity as it aims at implementing performance and model correctness with the simplest means possible. Human tissue could be modeled in many different ways and using sophisticated algorithms. Simple design, on the other hand, requires that physical models should only be as complex as necessary to fulfill the given purpose. To compare different models and their simplicity, statistical tests were found useful (Widmer and Hu, 2010).