Towards Quality-Aware Development and Evolution of Enterprise Information Systems

Oliver Hummel
Software Engineering Group University of Mannheim 68131 Mannheim

Christof Momm
FZI Research Center for Information Technology 76131 Karlsruhe

Susan Hickl
AIFB Institute University of Karlsruhe 76128 Karlsruhe

hummel@informatik.unimannheim.de ABSTRACT

momm@fzi.de

susan.hickl@aifb.unikarlsruhe.de

Information systems have been used to support business processes for a long time. Consequently, there has been an ongoing trend towards connecting and integrating the isolated IT solutions of enterprises into coherent systems in order to support the seamless execution of business processes electronically. Due to the often business critical nature of the processes such systems need to adhere to service level agreements that guarantee quality aspects such as a specific throughput or availability for a given process. However, a key weakness of existing development approaches for information systems is that they mostly focus on functional aspects of system development and lack an integrated view between different stakeholders and views in development, e.g. between business process management and software architecture. In this paper we introduce a novel approach for universal und uniform modeling of non-functional system properties that bridges the four areas of business and use case modeling as well as architecture and component design. By means of an example process, we first identify the key weaknesses of existing development methodologies and then derive the challenges for an improved approach. After that we describe the central aspects of our envisaged composition approach for non-functional requirements and how it might be supported by a novel breed of CASE tools in the future.

1. INTRODUCTION
Ultimately, quality in software development and business process management is a measure of the degree to which a system or a process fits the purpose for which it was constructed. It often determines whether the underlying development effort is deemed to be a success or a failure. Despite its importance, however, in most software-related IT projects today, quality is usually treated as a secondary issue that needs to be added to a system once it has been completed (e.g. by testing). This is particularly the case in the domain of business software, which is leading the push towards new system design and application development paradigms based on business processes, workflows, services and components [1-4]. The declared goal of these new approaches is to align business and IT requirements in order to increase flexibility in the face of evolving requirements. At the present level of maturity though, it is already a challenge to interrelate business processes and IT from a functional point of view. Consequently, quality requirements are typically treated separately for business process descriptions, software requirements and architectural as well as component specifications. In other words, the comprehensive alignment of quality-related requirements has not been sufficiently addressed so far. This, however, is crucial for an accountable business solution which truly aligns business and technical requirements. The main reason for this poor support of quality-related requirements in our opinion is that planning and developing enterprise information systems (EIS) clearly lacks methods and tools that provide integrated views on, and decision support for, functionality and quality from technical and business points of view. Such a tool-supported, quality-aware design approach for EIS inevitably involves various concerns from business-related and technical areas. The business layer, for example, comprises business strategy and business process design, also known as business engineering [5], whereas the technical layer involves the writing of use cases [6], the creation of a software/system architecture [7], and component design [8]. Today, each of these areas has a particular notion of quality and comes with rather isolated methodologies and tools for managing it. For example, there are business process management suites like [9][10] and tools for the early evaluation of a software architectures performance like [11][12]. However, these approaches are typically used in isolation. This separation of concerns between business analysts, software architects and developers, is essential to cope with the enormous functional complexity of the systems to be built. On the other hand, however, such a decoupled approach

Categories and Subject Descriptors

D.2.10 [Software Engineering]: Design methodologies.

General Terms
Management, Measurement, Performance, Design, Economics.

Keywords
software quality prediction, enterprise information systems.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC10, March 22-26, 2010, Sierre, Switzerland. Copyright 2010 ACM 978-1-60558-638-0/10/03$10.00.

137

makes it nearly impossible to find the globally optimal solution in terms of the overall system quality. Figure 1 depicts the four main influences on the overall quality of an enterprise information system we briefly mentioned before. Business process management (BPM) is typically closely related with the design of the overall system architecture (SWA). Likewise it is the main source for deriving the use cases of the system which are in turn the main source for the functionality that needs to be implemented in the system by developing new components or reusing existing ones.
Goal-oriented Business Process Management Integrated Quality-aware Models and Decision Support Component Development / Reuse User Case / User Interaction Development

problem using a practical example from one of our universities IT landscapes in section 2. Based on this, we more precisely illustrate the challenges that existing approaches are faced with in section 3 and propose in section 4 to define a shared understanding of quality that brings together the concerns of the various viewpoints introduced in Figure 1. In other words, we strive to reveal the relationships between the quality characteristics of the various areas involved, sketch a composition approach for non-functional requirements and show how it might be supported by a novel breed of CASE tools in the future. Section 5 summarizes our contributions and concludes the paper.

2. PROBLEM STATEMENT
This section introduces our understanding of a state of the art process for developing EIS in a quality-aware manner. In order to facilitate a better understanding of our argumentation we first provide a practical example in the next subsection. Based on this scenario, we particularly demonstrate that in case of qualitydriven development, a strict top-down approach is not adequate and the four viewpoints depicted in Figure 1 have to be equally considered (without assuming a certain top-down direction as it is the case today).

System/ SoftwareArchitecture (SWA)

Figure 1: Quality-Aware Development Model. Recent approaches for the service-oriented design of business systems like [13-15], already promote business-process-oriented design and development of software solutions and therefore provide a means for linking business processes with the software (service) architecture, even considering quality objectives [16][17]. So far, however, all these approaches propose a topdown methodology: business-level requirements are stepwise refined and translated into lower level business and technical requirements. This certainly is a good starting point, but does not address the issue in its entirety. Following these approaches, the functional system design is always derived from the blueprint of a business process. Thus, quality objectives determined for the system (i.e. process) level are considered as constant. However, in some cases it might be much better in terms of cost-benefit ratio to feed back results gained on a lower (i.e. technical) level (e.g. simulation results) in order to improve the overall system quality and to revise business process requirements and design instead of trying to meet the original objectives. Thus, we argue that instead of a purely top-down quality specification process a comprehensive approach to quality optimization for business solutions is required, which gives equal weight to the different viewpoints identified in Figure 1 during the whole lifetime of a system. Only in this way will it be possible to recognize and trace dependencies between business-level and technical quality aspects and to foresee the consequences of single design decisions. Nevertheless, to handle the enormous complexity of such decisions, we believe it is still essential to hold on to the existing separation of concerns within the different viewpoints for developing enterprise information systems and rather provide a glue for integrating existing methodologies, models and tools, which are so far used in isolation. This paper presents initial ideas for a comprehensive quality optimization process during EIS development. For the time being, we focus on the alignment of BPM and SWA. As part of our future work, we also envisage support for the other views and further consideration of evolution and maintenance aspects. The paper is structured as follows. First, we further motivate the

2.1 Running Example

To better illustrate our ideas we use the real-life project Karlsruher Integriertes InformationsManagement (KIM) as a running example. KIM targets the development of a universitywide business solution and to this end promotes a process- and service-oriented redesign of a universitys business processes along with the supporting IT [18]. Figure 2 provides an overview of the overall system architecture.
Central Administration Faculties Students

Study-Assistance-System (Access via KIM-Portal)

Facility Management Examination Management Course Management

Portal Layer Application Services Layer Basic Services Layer Legacy Systems Layer

Capturing Exam Results

Registration

BPEL

BPEL

Examination Management Services

Course Management Services

QIS POS

HIS LSF

MORADA

Integrated service-oriented Architecture (iSOA) Integrated service-oriented Architecture (iSOA)

Figure 2: Development of a University Business Solution. Accordingly, the required business solution is supposed to support a variety of a universitys typical tasks, for instance, processes concerned with facility management, examination management or course management. Moreover, a study assistance system, which integrates different services (such as registering for courses and exams) should be provided to students. As software architecture, we decided to use an integrated service-oriented architecture (iSOA), which distinguishes four layers: Legacy systems layer, basic services layer, application services layer and portal layer. On the legacy systems layer already existing applications are situated. The functionality offered by these applications should in future be provided as web services.

138

Therefore, adequate adapters (a.k.a wrappers) [19] have to be implemented. On basis of the developed basic services, application services can be created. The characteristic of these application services is twofold. On the one hand, application services are used for assembling coarse-grained messages from the business objects provided by the basic services and/or realizing business-relevant operations. In this case, the integration issue is focused. On the other hand, application services which directly support/realize business processes should be offered. In case these processes require user interactions, web-based portals are used to combine different types of user interfaces (e.g. task managers and task lists) with the applications services.

2.2 (Functional) Design Space

Development activities in this scenario can clearly be associated with the four viewpoints introduced in Figure 1. Business process management (BPM) defines business goals, designs business processes, identifies process goals, maps business processes to workflows, performs business process monitoring and based on this initiates process improvement [20][21] if necessary. Thus, the business processes form a good starting point for the elicitation of the functional requirements of the KIM information system. Use cases are thereby derived for those activities that require interplay of the system and one of its users [22]. Though often neglected in current requirements elicitation approaches user interface and interaction designs can also be derived at this point of the development process based on the use cases as for example illustrated in [23]. Based on the captured requirements, the systems operations can be derived and grouped into components [8] as well as the services they provide [1]. Then software architecting activities group these components together in order to shape the different layers of the iSOA. Another detailed description of a state of the art development process model can e.g. be found in [24] (which introduces an agile flavour to the Unified Process). Figure 3 shows a metamodel sketching the design space we face in enterprise information systems at a high level of abstraction.

As already discussed, an enterprise information system comprises the design of the supported business processes. Business processes serve or adhere to certain business goals and may be composed of various sub-processes. Eventually, processes are defined through a number of linked activities, which can be either carried out fully manually, in cooperation of user and computer system (User-Supported Activity) or solely by a computer system. Where users are involved, they are modeled as human resources and associated with activities. If an activity is supported by a software system, the required functionality is defined in terms of a software service or software functions, which specify the functionality while abstracting from the underlying concrete implementation. In user-supported activities, there are user interfaces available for accessing the functionality whereas system activities directly invoke the software services. The implementation of the software services thereby represents a composition of software systems and software components. Thus, the implementation could be a single and rather monolithic ERP solution or several more fine-grained software components. In any case, infrastructure resources are required for system operation. Software systems / components together with infrastructure resource make up a companys IT landscape, which has to be managed at runtime. This system operations phase is organized in terms of operational processes, which like business processes require human resources.

2.3 Supporting Quality in Design

A quality-aware development of enterprise information systems has to consider all the development perspectives illustrated in Figure 1. In order to handle complexity, however, work is usually shared amongst different roles. A business analyst for instance has to determine the most appropriate business process design for a given set of requirements. Design decisions often concern the number of hierarchies for structuring business processes, degree of automation and order of sequences for activities (control flow). In a similar way, a software architect has to provide an appropriate IT and software design. In this case, requirements are partly derived from business processes and design decisions are concerned with whether to buy complete software systems (which might not completely fit the problem) or develop custom solutions. In the latter case, the architect has to evaluate different design alternatives, like which design pattern variant to use, how to compose components, or how many load balancers are required. For any software design, custom development, out-ofthe-box solution or a hybrid approach, a decent capacity planning process regarding the required infrastructure resources as well as an adequate estimation of effort and cost for operating the resulting IT landscape is necessary. This should include qualification levels (quality) of the humans operating the system [25]. In a similar way, user interaction designers and component developers have to consider their quality requirements. However, none of the development process models mentioned in the previous subsection offers a continuous treatment of such quality aspects, yet. For the time being, if quality aspects are specified in the technical domains at all, this usually happens during the business process modelling and requirements elicitation phase and tends to be neglected until the very end of the development process when at least early versions of the system are available for evaluating the quality constraints. The following figure illustrates this typical distribution of effort for quality aspects in a waterfall-like development process today.

Figure 3: Design space for Enterprise Information Systems.

139

effort spent for quality aspects

introduced to reduce the expected maximum load of the server to 50 requests per minute. This example makes clear that the design of enterprise information systems is subject to far more quality decisions than widely acknowledged today. Consequently, the system development process is largely driven by functional considerations and large portions of the design space potentially leading to a better (i.e. usually cheaper) result from a nonfunctional perspective are therefore simply overlooked. To overcome this situation and to allow a quality tradeoff between various design options, obviously an integrated solution based on two quality values is necessary. In other words, this idea requires annotating every element identified in the metamodel (Figure 3) with two quality measures: First the qualities that have been specified for this element (the required qualities) and the actual (provided) qualites which can be achieved at this stage of development. Together these two can form the basis for rational quality optimizations within the system development process. We will discuss the challenges that arise in the context of this quality optimization in more detail in the next section.

implementation business process modelling & requirements elicitation system architecture & design

testing

time

Figure 4: Effort spent for quality definition and evaluation. Only recently, approaches such as [26][27] aim to develop forecast models for the architectural quality of a system in order to reduce the risk of eventually producing systems that are not capable of fulfilling their specified non-functional requirements. But these predictions are limited to the technical domain only and even in this case there are open issues left. For example, it is not fully clear yet how to find optimal solutions within a huge design space for a given set of quality requirements in a reasonable amount of time. The complexity of available quality prediction approaches in technical domains to a certain degree justifies the behaviour illustrated in Figure 4. However, it is fundamentally opposed to the quality awareness of the business domain where process designs are derived from business goals [21] and tools as presented in [28] are available for evaluating designs against key performance indicators, for instance concerning cost or availability. In other words, the quality-driven development of EIS systems currently faces a fundamental dilemma as managers and business process developers actually specify and evaluate quality requirements and pass them on to the technical personnel who then neglect them until a first implementation is available. This, however, might be too late, as subsequent changes to a systems architecture are usually very costly [29]. Even worse, a true quality optimization of EIS systems that explores the whole broadness of the design space is so far not feasible due to the limited means available today. In order to support a better understanding of our argumentation, we provide an example supporting this hypothesis. Let us consider the interplay between BPM and software architecture in case of our sample scenario. Looking at the process of registering for an examination, BPM provides a design for a fully automated registration process, which allows students to register as long as the deadline for registration has not expired. As the registration is offered through a web-based portal, one goal for this process is that its duration is less than 2 seconds. Taking into account historical information on students behavior, simulation of the business processes yielded the result that the software (service) involved has to support a maximum throughput of 100 invocations per minute. Software architecture takes this requirement and evaluates different design alternatives with the result that this requirement could only be supported by introducing several replications and load balancers that would significantly increase the hardware costs. However, if only 50 requests per minute would have to be supported, no additional machines would be required. With this information at hand, BPM would be able to revise the process design: e.g. registration slots depending on the matriculation number could have been

3. CHALLENGES
As already pointed out, these design decisions are driven to the same degree by functional and non-functional requirements, for instance regarding quality and costs. Following such a qualityaware approach, however, results in several new challenges. Figure 5 shows a conceptual metamodel, which will help to explain them

Figure 5: Conceptual Quality Metamodel. If we look at an enterprise information system and its numerous development aspects (business, user interaction, system and component design) from a 20,000 feet perspective, there are always various abstract specifications and designs, which would satisfy its functional requirements. If quality-related requirements were not considered, it would be sufficient to find exactly one appropriate process or system design. Otherwise, different feasible alternatives have to be further evaluated with regard to finding the optimal solution in terms of quality. In this context, we can observe the following major challenges: 1) Quality Metric Definition Quality is generally expressed in terms of quantifiable metrics in combination with objectives defined as target values. For all development areas introduced in Figure 1, meaningful quality metrics and target values are required. For the different areas various quality metrics have already been proposed, such as the UML SPT/MARTE profile in case of software architectures [30] or the workflow quality metrics defined in [31] or [32]. However, a comprehensive definition of metrics covering all areas is still

140

missing. A particular challenge therefore is to identify metrics that have significant impact on quality requirements of the other areas. More precisely, a comprehensive quality metric system is required, which reflects dependencies between internal and external quality metrics for the four different areas. 2) Quality Metric Assessment Having identified, associated and specified quality metrics, another challenge is to assess the concrete metric values for a given process or system design using an appropriate assessment methodology. Such a methodology can either be based on measurements (e.g. if an existing system is chosen) or prediction model (if new software is developed). Looking at current research in this sector it becomes clear that every quality metric requires its own, specific prediction approach. Up to now only a fraction of conceivable quality metrics is supported in an adequate way and it is still an open challenge to combine prediction/analysis approaches for the different areas. In addition to this, the combination of prediction and measurement-based approaches in case of hybrid make and buy scenarios has not been sufficiently addressed so far. 3) Utility Assessment The assessment of quality metrics (predicted or measured) results in a vector of metric values for a given design or implementation. To find the most appropriate design/implementation we have to express the utility (or value) of a given design alternative. Although a value-based approach to engineering has already been proposed in [33] some time ago, there is still little research on a formal specification of software architecture and workflow utilities taking user or stakeholder preferences into account. Only in case of web service offerings, many useful approaches are available, e.g. [34][35]. 4) Design-Space Exploration & Optimization Using a prediction-based approach to metric assessment allows evaluating design alternatives without having to implement them. As already pointed out, various prediction/analysis approaches are already available for the different areas, in particular business process management and software architecture. However, these approaches are usually limited to predict quality properties for a single given design and do not provide any automated decision support in case predictions indicate a violation of requirements. So far, decision makers have to manually interpret results, identify root cases and improve the models. A particular challenge is to develop approaches, which support automated exploration of a design space, and to find optimal solutions for a given set of requirements. For the single areas, several promising approaches already exist, e.g. [36] and [37] for software architecture models and [31] in case of business process modeling. But again, research and practice lacks approaches that combine the different points of view in a non-top-down fashion. Tackling these challenges, we strive for the ultimate goal of integrated reasoning about the EIS quality attributes contained in a given design space in order to find the optimal solution for a specific scenario not only in terms of functionality, but also in terms of quality. The approach should not only cover the initial development of solutions, but should also provide decision support in case of evolving requirements. The desired process in this case would be as follows: after having designed, evaluated and implemented an initial solution, existing prediction and

decision models are further calibrated on basis of real-life measurements. Based on the refined models, once again feasible modifications are explored and their impact on the overall quality is evaluated. To our best knowledge, research up to now has barely considered this particular problem. While the IT management community respects change management as a research topic and some work on decision support already exists (e.g. in [38]), business process management and software engineering lack approaches supporting automated quality-aware design evaluation and improvement.

4. QUALITY-AWARE DEVELOPMENT
So far, there is no development approach available, which adequately supports global decision making regarding business solution design and quality [39]. Thus, we have made the case in this paper that a new quality-aware approach for the development of business solutions is required. Since the full formulation of a process model comprising all four viewpoints introduced in Figure 1 is still under development we introduce how we currently imagine the interplay of BPMN und SWA in this context. Accordingly, Figure 6 illustrates our idea for qualityaware EIS development by means of a simplified sample process model, which is limited to an interaction between a business analyst and a software architect.
Simplified Tool-supported Quality-aware EIS Development Business Analyst Software Architect

Specify Business Requirements (Re-) Design Business Process (BP) Evaluate / Improve BP Design Derive Software Requirements (Re-)Design Software Architecture (SWA) Evaluate / Improve SWA Design
[Further Iteration]

[Further Iteration]

[Finished]

Adapt Business Requirements Re-Design Business Process (BP) Evaluate / Improve BP Design

[Finished] [Propose adaptation] [Accept business process design]

[Further Iteration]

[Finished]

[Adaptation of SWA required]

Figure 6: Quality-aware EIS development process by example. We thereby assume that within each activity functional as well as quality requirements are considered. The main enhancements are: a tool-supported evaluation of designs along with decision support for finding improved designs within the different areas;

141

support for initially translating requirements on a higher level into requirements on a lower level and a consideration of bottom-up feedback loops. The depicted sample process for instance allows an adaptation of business requirements based on the results of an evaluation of (different) software architecture aspects and vice versa. The traceability of business process activities via software requirements towards software components has long been identified (e.g. [40]) as one of the most important factors when dealing with business information systems. Hence, we believe that it is crucial to support quality optimizations with an appropriate CASE tool. In our vision such a tool could be based on common process modeling or UML tools that are already in use to depict high-level views of business processes. The UML activity diagram sketched in the following figure gives an example for such a process.
Provide Examination Lecturer Exam Organizer Take Examination Student

1. 2. 3. 4.

cost per invocation required time per invocation availability reliability

1000 3 0.98 0.998

Plan Exam Exam Registration Prepare and Conduct Exam Event Acertain Exam Results Process Exam Registrations Capture Exam Results Publish Exam Results

Choose Exam

Thus, on one hand, the basic idea is to support the assessment of these metrics on the business process level, for instance by using simulations, and on the other hand to provide algorithms for decomposing higher level into lower level elements again annotated with quality information. At the highest level, the desired quality of the overall process is specified by the process designer. In other words, he has to specify how expensive the process is allowed to be, how reliable it needs to be and so on. During the decomposition of the process into activities, the designer assigns a fraction of the disposable quality (the required quality) to each activity such that the required overall quality requirements can be met. During the design process of the system each activity needs to be decomposed by the process designer into further elements such as depicted in Figure 8 for the Register for Exam activity from Figure 7.
<<Process>> Examination

Register for Exam

Take Exam

Receive Exam Result

cost: 1000 EUR required time: 3 month availability: 0.98 reliability: 0.998 1 300

<<Resource>> Student
cost: 0 EUR required time: 10 min availability: 1.0 reliability: 0.999

1 1

Figure 7: Flow of the examination process in the university example. As another example, Figure 7 shows the process of offering, taking and grading an exam in our University setting as introduced earlier. It is modelled as a UML activity diagram showing the various roles in the process in vertical swim lanes. In order to provide a continuous and unified quality estimation and simulation with the help of a tool it would be necessary to annotate all activities in the process as well as the process itself with two collections of quality metrics, one for the required quality of an activity and one for the actual provided quality of an activity. While the former contains the demanded amount of quality from the higher-level activity, the latter delivers the actual reachable amount of quality composed of the qualities of the subactivities that make up the given activity. Since we need to correlate internal and external metrics in the further course of our research, the idea of uniformly condensing quality information in vectors and relating internal and external values through a weighting matrix as originally proposed by [41] seems very promising. Thus, a CASE tool should support an annotation of our process elements with appropriate values as for example shown in Figure 8. However, selecting the quality values actually interesting for the vector is not trivial. Although in principle any quality metric from the EIS domain could be added, it makes more sense to consider only those that can be uniquely applied for all elements identified in our metamodel. For the time being, we have been able to identify four dimensions that can be used in quality vectors across all viewpoints, namely

<<User Supp. Act.>> Register for Exam

cost: 50 EUR required time: 30 min availability: 0.98 reliability: 0.998

<<Resource>> System
1 cost: 30 EUR required time: 30 min availability: 0.98 reliability: 0.998

<<Service>> Register for Exam

cost: 1 Euro required time: 30 s availability: 0.98 reliability: 0.998

50

<<UI>> Register for Exam

cost: 2 EUR required time: 30 min availability: 0.98 reliability: 0.998

Figure 8: Exemplary decomposition of activity in further elements. In Figure 8 the examination process has been decomposed into a number of activities and further elements required to develop a software system supporting the designed process. The elements available for the decomposition (the stereotypes in Figure 8) have been defined in the metamodel in Figure 3. We expect to find a limited number of patterns that will cover most of the decompositions that can occur and thus can be encoded and supported by a tool. Due to a lack of space we have only shown the use supported activity register for exam which we highlighted in Figure 7. This user supported activity (which is equivalent to a use case in software requirements engineering) becomes decomposed into two resources, namely the System and its user (the Student) that are required to accomplish it. The system in turn needs to offer a service that implements the functionality of exam registration as well as an UI the student can use. In a complete example the service would be further decomposed into components, of course. All the elements in the figure are annotated with the appropriate required quality values

142

as estimated by their respective designers. The multiplicities between the activity and the system indicate that a peak usage of 50 simultaneous invocations needs to be supported by one system. In turn, the multiplicity of 300 between process and user supported activity means that a maximum of 300 simultaneous instances need to be supported. A tool, supporting the comparison of required and provided quality vectors, would accompany the functional development process of the system and not only help to trace functional requirements, but also the qualities related to them. As soon as the decomposition reaches a level where the quality can be simulated or estimated, the calculated values (the provided quality) can be compared with the required quality on the given level. As long as the provided quality is better than the required quality everything is fine and the provided qualities can be propagated up to the root of the quality tree. However, in the case that the modelling has revealed a potential quality or cost problem, this would also be propagated up and would directly indicate where it makes sense to contemplate changes to the required qualities or even to the process as we have discussed it in section 2.3. In the best case the process designer might recognize a limited impact of the problem and thus be able to relieve the constraints of the required quality accordingly to overcome this problem. Another solution might be to play around with the quality constraints of multiple activities in order to find a better distribution. However, in the worst case it might become necessary to fully redesign the process (and the system as far as it is specified and built along with it) in order to find a better solution. Obviously, an appropriate CASE tool should be able to handle multiple models for each activity in a tree-like structure.

should be distributed amongst various processes running on the same machine. Thus this is clearly subject to future work.

6. REFERENCES
[1] [2] T. Erl, SOA: Principles of Service Design: Prentice Hall, 2007. N. Bieberstein, S. Bose, M. Fiammante, K. Jones, and R. Shah, Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap: Prentice Hall, 2006. D. Krafzig, K. Banke, and D. Slama, Enterprise SOA: Service-Oriented Architecture Best Practices (The Coad Series): Prentice Hall, 2004. M. Papazoglou, Web Services: Principles and Technology: Addison-Wesley, 2008. J. Schelp and R. Winter, "Business application design and enterprise service design: a comparison", International Journal of Services Sciences, vol. 1, pp. 206-224, 2008. A. Cockburn, Writing effective use cases: AddisonWesley Reading, MA, 2002. R. Reussner and W. Hasselbring, Handbuch der SoftwareArchitektur: dpunkt-Verlag, 2006. C. Atkinson, D. Brenner, P. Bostan, G. Falcone, M. Gutheil, O. Hummel, M. Juhasz, and D. Stoll, "Modeling Components and Component-Based Systems in KobrA", in The Common Component Modeling Example: Comparing Software Component Models, A. Rausch, R. Reussner, R. Mirandola, and F. Plasil, Eds.: Springer, 2008. A. Oberweis, G. Scherrer, and W. Stucky, "INCOME/STAR: Methodology and tools for the development of distributed information systems", INFORMATION SYSTEMS-OXFORD-PERGAMON PRESS-, vol. 19, pp. 643-643, 1994. A. W. Scheer, ARIS--business process frameworks: Springer, 1998. S. Becker, H. Koziolek, and R. Reussner, "The Palladio component model for model-driven performance prediction", The Journal of Systems & Software, vol. 82, pp. 3-22, 2009. R. H. Reussner, H. W. Schmidt, and I. H. Poernomo, "Reliability prediction for component-based software architectures", The Journal of Systems & Software, vol. 66, pp. 241-252, 2003. S. Roser, B. Bauer, and J. P. Muller, "Model-and Architecture-Driven Development in the Context of Cross-Enterprise Business Process Engineering", in IEEE International Conference on Services Computing (SCC'06), 2006, pp. 119-126. S. K. Johnston and A. W. Brown, "A Model-Driven Development Approach to Creating Service-Oriented Solutions", in International Conference on ServiceOriented Computing (ICSOC 06), 2006, pp. 624636. M. P. Papazoglou and W. J. van den Heuvel, "ServiceOriented Design and Development Methodology", Int. J. of Web Engineering and Technology (IJWET), 2006. F. Melchert, R. Winter, and M. Klesse, "Aligning Process Automation and Business Intelligence to Support Corporate Performance Management", in Tenth Americas Conference on Information Systems, New York, 2004, pp. 4053-4063.

[3]

[4] [5]

[6] [7] [8]

[9]

5. CONCLUSION
In this paper, we have laid out our understanding of shortcomings in the development of enterprise information systems as it is done today. We have focused on the quality aspects of software development and identified a lack of a unified quality model that spans all phases of software development, including operation and maintenance. Thus, we proposed an initial template for such a model based on a meta-model of design artifacts we have found in state of the art development processes. We have demonstrated the propagation of quality through a decomposition hierarchy by means of a practical example. The main advantage of this approach is the possibility to assess whether quality constraints can be met as soon as simulated or measured values are available. Thus, it becomes feasible to act on this valuable feedback a lot earlier in the development process as this is typically feasible today. A prerequisite for the practical application of such an integrated model is, however, establishing a much deeper understanding of the relation between internal and external metrics available today, in order to achieve better forecasting models for each of the four perspectives mentioned in Figure 1 (namely business process modeling, software requirements engineering, including user interface design, software architecture and component design). Although the tight integration of these four perspectives is already a significant step forward, it still lacks the operational perspective which has a significant impact on the actual quality of the process. Unfortunately, the relation of a running process and its operational qualities is not that simple to model, as for example it is not clear how the costs of hardware [10] [11]

[12]

[13]

[14]

[15]

[16]

143

[17]

[18]

[19] [20]

[21]

[22]

[23]

[24] [25]

[26]

[27]

[28]

[29]

R. Grnmo and M. C. Jaeger, "Model-driven methodology for building qoS-optimised web service compositions", in 5th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS05), pp. 6882. P. Freudenstein, W. Juling, L. Liu, F. Majer, A. Maurer, C. Momm, and D. Ried, "Architektur fr ein universittsweit integriertes Informationsund Dienstmanagement", in INFORMATIK 2006, Dresden, 2006, pp. 50-54. E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns: Addison-Wesley Reading, Mass, 2002. M. zur Muehlen and M. Rosemann, "Multi-Paradigm Process Management", in Fifth Workshop on Business Process Modeling, Development, and Support-CAiSE Workshops, 2004. F. Melchert and R. Winter, "The Enabling Role of Information Technology for Business Performance Management", in IFIP International Conference on Decision Support Systems, 2004. R. M. Dijkman and S. M. M. Joosten, "An Algorithm to Derive Use Cases from Business Processes", in 6th International Conference on Software Engineering and Applications (SEA), Boston, USA, 2002, pp. 679-684. S. Lauesen and M. B. Harning, "Virtual windows: Linking user tasks, data models, and interface design", IEEE software, pp. 67-75, 2001. C. Larman, Applying UML and patterns: Prentice Hall PTR, 2005. E. Ammenwerth, R. Breu, and B. Paech, "User-Oriented Quality Assessment of IT-Supported Healthcare Processes ", in 3rd Int. Workshop on Process-oriented information systems in healthcare, Ulm, Germany, 2009. S. Becker, H. Koziolek, and R. Reussner, "Model-based performance prediction with the palladio component model", 2007, pp. 54-65. L. G. Williams and C. U. Smith, "Performance evaluation of software architectures", in 1st international workshop on Software and performance, 1998, pp. 164-177. K. Lenz, M. Mevius, and A. Oberweis, "Process-Oriented business performance management with petri nets", in The 2005 IEEE International Conference on e-Technology, eCommerce and e-Service (EEE'05), 2005, pp. 89-92. B. W. Boehm, "Verifying and validating software requirements and design specifications", IEEE software, vol. 1, pp. 75-88, 1984.

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40] [41]

M. Woodside, "From Annotated Software Designs (UML SPT/MARTE) to Model Formalisms", Lecture notes in computer science, vol. 4486, p. 429, 2007. J. Cardoso, A. Sheth, J. Miller, J. Arnold, and K. Kochut, "Quality of service for workflows and web service processes", Web Semantics: Science, Services and Agents on the World Wide Web, vol. 1, pp. 281-308, 2004. M. Heravizadeh, J. Mendling, and M. Rosemann, "Dimensions of Business Processes Quality (QoBP)", in 6th International Conference on Business Process Management Workshops, Milan, Italy, 2008. B. Boehm, "Value-based software engineering", ACM SIGSOFT Software Engineering Notes, vol. 28, p. 1, 2003. S. Lamparter, A. Ankolekar, R. Studer, and S. Grimm, "Preference-based selection of highly configurable web services", in 16th international conference on World Wide Web, 2007, pp. 1013-1022. M. Paolucci, T. Kawamura, T. R. Payne, and K. Sycara, "Semantic matching of web services capabilities", Lecture notes in computer science, pp. 333-347, 2002. J. Xu, "Rule-based automatic software performance diagnosis and improvement", in 7th international workshop on Software and performance, 2008, pp. 1-12. A. Martens and H. Koziolek, "Automatic, model-based software performance improvement for component-based software designs", in 6th International Workshop on Formal Engineering approaches to Software Components and Architectures (FESCA), 2009. T. Setzer, K. Bhattacharya, and H. Ludwig, "Decision support for service transition management Enforce change scheduling by performing change risk and business impact analysis", in IEEE Network Operations and Management Symposium (NOMS 2008), 2008, pp. 200-207. A. Tang, J. Han, and R. Vasa, "Software Architecture Design Reasoning: A Case for Improved Methodology Support", Software, IEEE, vol. 26, pp. 43-49, 2009. M. Jarke, "Requirements tracing", Communications of the ACM, vol. 41, 1998. P. Vitharana, H. Jain, and F. Zahedi, "Strategy-based design of reusable business components", IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, vol. 34, pp. 460-474, 2004.

144