رویکرد گردش کار ساختاریافته برای حمایت از رشد یافتن

This work aims at explicitly modelling key concepts of the evolution process to support the product development process of complex multi-disciplinary systems such as Magnetic Resonance Imaging (MRI) systems. The key concepts span over different domains of the product development process: product use (workflow models), system functionality (Function–Behaviour–State modelling), component interfaces (Design Structure Matrix and Interface model) and the organisational view (stakeholder analysis). By having an explicit view on these domains, effectiveness of change management is improved by showing how changes in one domain propagate to other domains. The focus on simplicity of the models and human understandable language is essential to ensure understanding by all (non-engineering) stakeholders such as nurses and physicians from the start of the evolution process. From these models a modularisation of the system can be extracted. The modularisation separates closely connected elements and thereby reduces the risk of unknown future changes having a high impact. The method is illustrated using a real industrial example, namely, the development of a product that facilitates intra-operative MRI.

The complexity of systems has been discussed extensively in literature [1], [2], [3], [4] and [5] and can be split up into the complexity of the system and the complexity of the design process. Not only are systems increasing in size (i.e. number of parts, lines of code, integrated functionalities), but the developing organisations are becoming larger, geographically scattered and more multi-disciplinary. Both the system and the design process sides of complexity should be properly addressed in attempting to create a complex system that needs to adapt to changing requirements. A new generation of contemporary complex systems (such as Magnetic Resonance Imaging (MRI) systems) cannot be designed from scratch. The time and investment required for a completely new design would exceed the available time to market and expected profits [6]. The design process for complex systems usually begins with existing systems and can be characterised as a re-design process. There is a paradox in choosing a re-design over a completely new design in order to reduce complexity, because by doing so a different kind of complexity is introduced in the form of managing changes. This work looks at the MRI patient handling system as an example of a complex system re-design. The complexity of the MRI system can be characterised by the eight million lines of code, three Tesla helium cooled superconductive magnet, and a geographically distributed multi-disciplinary development team. Additionally its applications are all in the medical domain where the end-users are physicians, nurses and other medical experts with limited time for non-medical activities and can only be exposed to a basic form of technical information while communicating about the design. Conversely product development engineers have difficulties in accessing real experiences during MRI operations. These stakeholder aspects increase the complexity of the MRI development process. One of the key features of complexity management is change management [7]. Changes to the MRI system design are driven by amended medical domain user requirements, technological advancements resulting from research and development activities, and the new (medical) devices that have to be connected. Rowe et al. [8] and [9] recognised that changes in these three aspects are the key concepts driving system evolvability which they define as the ability of a system to adapt to, or cope with change in requirements, environment and implementation technologies [8]. Rowe et al. do not explicitly discuss what is regarded as part of the ‘system’ in their definition. However in this work, system evolution explicitly covers the combination of the system design and designers. Here the task of the MRI design team is to translate the changes currently requested into a new system with minimal impact and costs, while safeguarding the long term system evolvability. The strategy followed by designers to implement any changes should therefore be one of ‘least regret’. When evolvability is not safeguarded during the design process, incorporating unknown future changes could be troublesome or even impossible. The most difficult future changes to accommodate for and to minimise the impact of are the unknown future changes. These changes cannot be fully predicted; what can be predicted for unknown future changes are the aspects or domains of the design that they will affect. Rowe et al. [9] show that the changes driving evolution affect four aspects; stakeholder needs, environment, implementation technologies, and requirements. Changes in these four aspects result in changes in system such as; user workflow, functions, behaviour, entities, and involved stakeholders. Although complete preparation for unknown future changes is impossible, designers can prepare by modelling the aspects of systems in which changes typically occur. A system is defined as a set of interrelated, interdependent elements that form a complex whole. Typically, changes in an element have the highest impact on the element itself and the immediate surrounding interrelated elements. This is how changes propagate through a system [7] similar to an attenuating ring-wave travelling on water. The further elements are positioned from the source element that is changed, the lower the ‘amplitude’ of the impact. To minimise the impact of changes their propagation should be restricted as much as possible. A ‘least regret strategy’ therefore boils down to ensuring the impact of unknown future changes on the system remain local. A least regret strategy is believed to benefit from a modular system in which closely interrelated elements are grouped together in such a way that unknown future changes in any of these elements will only have a local effect with minimal impact. Therefore, in order to implement a ‘least regret strategy’, this work follows two thoughts. First emphasis should be placed on the modelling of different system aspects that are likely to be subject to unknown future changes and the interrelationships amongst these aspects. This modelling is done to create a common stakeholder understanding and the alignment of stakeholder expectations. Secondly, loosely connected sub-systems should be separated to reduce the risk of future changes having a costly global impact on the whole system. This paper hypothesizes that a common stakeholder understanding and an explicit relationship between requirement changes and system aspect changes can be articulated by an interlinked set of simple, easy to produce, domain-independent models. The proposed set of models in this work focus on the early phases of development and can be used without prior training by all relevant stakeholders. The proposed set of modelling aspects are: 1. User workflow flowchart models. 2. A system functionality tree graph. 3. A graph of system entities and behaviours. 4. A system matrix representation of entity are interrelationships. 5. A graph representation of the impact of the proposed changed system design compared to the existing system design. The method presented here to capture the high level of abstraction user needs and system functionality uses workflow models connected to function models. Connecting the function models to interface models is necessary in order to relate the high level models to the implementation level models. Following this introduction, a brief overview of the related work and background from literature is presented. Section 3 will explain the structured workflow approach in more detail and Section 4 presents a real industrial example where the method was applied in the development of an intra-operative magnetic resonance imaging system. Sections 5 and 6 discuss the results and conclude this paper respectively.

6. Conclusions This paper hypothesised that a common stakeholder understanding and explicit linkage of how changes in requirements relate to changes in system architecture can be articulated by an interlinked set of simple, easy to produce, domain independent models that are based on a combination of the initial system and the changes made to that system. This paper proposed a set of linked graphical models that support the evolution process. The communication during the evolution process is facilitated by capturing the initial situation, the proposed changes to the use requirements, functionality and components of the system and a view on the final design. Clear and understandable communication makes sure that stakeholders are aligned and that the development addresses the issues that should be addressed, effectiveness. Effectiveness of the evolution process is a big part of evolvability. Therefore this method is believed to improve evolvability. None of the proposed models are limited to certain domains. Workflows, functions, interfaces for example are not limited to describing just software, mechanisms, neuro surgery or any other domain. This cross-domain, multi-disciplinary nature of the proposed models is important in trying to improve evolvability in general. The models proposed proved easy to produce and maintain. Since modelling is a supportive activity in the design process it should not be to invasive. The objectives of the models are just to make the proposed changes explicit and to create a shared understanding. This gives the stakeholders focus on the intended effects and not on the models themselves. Research into metrics for evolvability besides modularity metrics remains future work. Having metrics for evolvability and understanding what they mean is a complicated matter. Although using the metric should make the problem less complex, such a metric might be difficult to obtain. Other future work includes automating tedious parts of the proposed method by using the computer friendly DSM. Applying the method and models to industrial design problems with different characteristics from the presented example is also future work. Different design problems might be characterised by different scale, different domains involved, different levels of maturity of the existing systems, etc. Theoretically, however, the authors do not see any fundamental objections to applying the method elsewhere, because the method tries to address domain independent issues. Testing this in real applications remains future work though.