VIVACE: A framework for the systematic evaluation of variability support in process-aware information systems

ContextThe increasing adoption of process-aware information systems (PAISs) such as workflow management systems, enterprise resource planning systems, or case management systems, together with the high variability in business processes (e.g., sales processes may vary depending on the respective products and countries), has resulted in large industrial process model repositories. To cope with this business process variability, the proper management of process variants along the entire process lifecycle becomes crucial.ObjectiveThe goal of this paper is to develop a fundamental understanding of business process variability. In particular, the paper will provide a framework for assessing and comparing process variability approaches and the support they provide for the different phases of the business process lifecycle (i.e., process analysis and design, configuration, enactment, diagnosis, and evolution).MethodWe conducted a systematic literature review (SLR) in order to discover how process variability is supported by existing approaches.ResultsThe SLR resulted in 63 primary studies which were deeply analyzed. Based on this analysis, we derived the VIVACE framework. VIVACE allows assessing the expressiveness of a process modeling language regarding the explicit specification of process variability. Furthermore, the support provided by a process-aware information system to properly deal with process model variants can be assessed with VIVACE as well.ConclusionsVIVACE provides an empirically-grounded framework for process engineers that enables them to evaluate existing process variability approaches as well as to select that variability approach meeting their requirements best. Finally, it helps process engineers in implementing PAISs supporting process variability along the entire process lifecycle.     

Variability in quality attributes of service-based software systems: A systematic literature review

ContextVariability is the ability of a software artifact (e.g., a system, component) to be adapted for a specific context, in a preplanned manner. Variability not only affects functionality, but also quality attributes (e.g., security, performance). Service-based software systems consider variability in functionality implicitly by dynamic service composition. However, variability in quality attributes of service-based systems seems insufficiently addressed in current design practices.ObjectiveWe aim at (a) assessing methods for handling variability in quality attributes of service-based systems, (b) collecting evidence about current research that suggests implications for practice, and (c) identifying open problems and areas for improvement.MethodA systematic literature review with an automated search was conducted. The review included studies published between the year 2000 and 2011. We identified 46 relevant studies.ResultsCurrent methods focus on a few quality attributes, in particular performance and availability. Also, most methods use formal techniques. Furthermore, current studies do not provide enough evidence for practitioners to adopt proposed approaches. So far, variability in quality attributes has mainly been studied in laboratory settings rather than in industrial environments.ConclusionsThe product line domain as the domain that traditionally deals with variability has only little impact on handling variability in quality attributes. The lack of tool support, the lack of practical research and evidence for the applicability of approaches to handle variability are obstacles for practitioners to adopt methods. Therefore, we suggest studies in industry (e.g., surveys) to collect data on how practitioners handle variability of quality attributes in service-based systems. For example, results of our study help formulate hypotheses and questions for such surveys. Based on needs in practice, new approaches can be proposed.     

Supporting distributed product configuration by integrating heterogeneous variability modeling approaches

ContextIn industrial settings products are developed by more than one organization. Software vendors and suppliers commonly typically maintain their own product lines, which contribute to a larger (multi) product line or software ecosystem. It is unrealistic to assume that the participating organizations will agree on using a specific variability modeling technique—they will rather use different approaches and tools to manage the variability of their systems.ObjectiveWe aim to support product configuration in software ecosystems based on several variability models with different semantics that have been created using different notations.MethodWe present an integrative approach that provides a unified perspective to users configuring products in multi product line environments, regardless of the different modeling methods and tools used internally. We also present a technical infrastructure and a prototype implementation based on web services.ResultsWe show the feasibility of the approach and its implementation by using it with the three most widespread types of variability modeling approaches in the product line community, i.e., feature-based, OVM-style, and decision-oriented modeling. To demonstrate the feasibility and flexibility of our approach, we present an example derived from industrial experience in enterprise resource planning. We further applied the approach to support the configuration of privacy settings in the Android ecosystem based on multiple variability models. We also evaluated the performance of different model enactment strategies used in our approach.ConclusionsTools and techniques allowing stakeholders to handle variability in a uniform manner can considerably foster the initiation and growth of software ecosystems from the perspective of software reuse and configuration.     

When agile meets the enterprise

ContextWhile renowned agile methods like XP and Scrum were initially intended for projects with small teams, traditional enterprise environments, i.e. environments where plan-driven development is prevalent, have also become attracted by the promises of a faster time to market through agility. Agile software development methods emphasize lightweight software development. Projects within enterprise environments, however, are typically confronted with a large and complex IT landscape, where mission-critical information is at play whose criticality requires prudence regarding design and development. In many an organization, both approaches are used simultaneously.ObjectiveFind out which challenges the co-existence of agile methods and plan-driven development brings, and how organizations deal with those challenges.MethodWe present a grounded theory of the challenges of using agile methods in traditional enterprise environments, based on a Grounded Theory research involving 21 agile practitioners from two large enterprise organizations in the Netherlands.ResultsWe organized the challenges under two factors: Increased landscape complexity and Lack of business involvement. For both factors, we identify successful mitigation strategies. These mitigation strategies concern the communication between the agile and traditional part of the organization, and the timing of that communication.ConclusionAgile practices can coexist with plan-driven development. One should, however, keep in mind the context and take actions to mitigate the challenges incurred.     

Semantic enrichment process: An approach to software component reuse in modernizing enterprise systems

In today’s dynamic business environments, organizations are under pressure to modernize their existing software systems in order to respond to changing business demands. Service oriented architectures provide a composition framework to create new business functionalities from autonomous building blocks called services, enabling organizations to quickly adapt to changing conditions and requirements. Characteristics of services offer the promise of leveraging the value of enterprise systems through source code reuse. In this respect, existing system components can be used as the foundation of newly created services. However, one problem to overcome is the lack of business semantics to support the reuse of existing source code. Without sufficient semantic knowledge about the code in the context of business functionality, it would be impossible to utilize source code components in services development. In this paper, we present an automated approach to enrich source code components with business semantics. Our approach is based on the idea that the gap between the two ends of an enterprise system—(1) services as processes and (2) source code—can be bridged via similarity of data definitions used in both ends. We evaluate our approach in the framework of a commercial enterprise systems application. Initial results indicate that the proposed approach is useful for annotating source code components with business specific knowledge.     

Constraints for the design of variability-intensive service-oriented reference architectures – An industrial case study

ContextService-oriented architecture has become a widely used concept in software industry. However, we currently lack support for designing variability-intensive service-oriented systems. Such systems could be used in different environments, without the need to design them from scratch. To support the design of variability-intensive service-oriented systems, reference architectures that facilitate variability in instantiated service-oriented architectures can help.ObjectiveThe design of variability-intensive service-oriented reference architectures is subject to specific constraints. Architects need to know these constraints when designing such reference architectures. Our objective is to identify these constraints.MethodAn exploratory case study was performed in the context of local e-government in the Netherlands to study constraints from the perspective of (a) the users of a variability-intensive service-oriented system (municipalities that implement national laws), and (b) the implementing organizations (software vendors). We collected data through interviews with representatives from five organizations, document analyses and expert meetings.ResultsWe identified ten constraints (e.g., organizational constraints, integration-related constraints) which affect the process of designing reference architectures for variability-intensive service-oriented systems. Also, we identified how stakeholders are affected by these constraints, and how constraints are specific to the case study domain.ConclusionsOur results help design variability-intensive service-oriented reference architectures. Furthermore, our results can be used to define processes to design such reference architectures.     

Current state and potential of variability management practices in software-intensive SMEs: Results from a regional industrial survey

ContextMore and more, small and medium-sized enterprises (SMEs) are using software to augment the functionality of their products and offerings. Variability management of software is becoming an interesting topic for SMEs with expanding portfolios and increasingly complex product structures. While the use of software product lines to resolve high variability is well known in larger organizations, there is less known about the practices in SMEs.ObjectiveThis paper presents results from a survey of software developing SMEs. The purpose of the paper is to provide a snapshot of the current awareness and practices of variability modeling in organizations that are developing software with the constraints present in SMEs.MethodA survey with questions regarding the variability practices was distributed to software developing organizations in a region of Sweden that has many SMEs. The response rate was 13% and 25 responses are used in this analysis.ResultsWe find that, although there are SMEs that develop implicit software product lines and have relatively sophisticated variability structures for their solution space, the structures of the problem space and the product space have room for improvement.ConclusionsThe answers in the survey indicate that SMEs are in situations where they can benefit from more structured variability management, but the awareness need to be raised. Even though the problem space similarity is high, there is little reuse and traceability activities performed. The existence of SMEs with qualified variability management and product line practices indicates that small organizations are capable to apply such practices.     

Coevolution of variability models and related software artifacts

Variant-rich software systems offer a large degree of customization, allowing users to configure the target system according to their preferences and needs. Facing high degrees of variability, these systems often employ variability models to explicitly capture user-configurable features (e.g., systems options) and the constraints they impose. The explicit representation of features allows them to be referenced in different variation points across different artifacts, enabling the latter to vary according to specific feature selections. In such settings, the evolution of variability models interplays with the evolution of related artifacts, requiring the two to evolve together, or coevolve. Interestingly, little is known about how such coevolution occurs in real-world systems, as existing research has focused mostly on variability evolution as it happens in variability models only. Furthermore, existing techniques supporting variability evolution are usually validated with randomly-generated variability models or evolution scenarios that do not stem from practice. As the community lacks a deep understanding of how variability evolution occurs in real-world systems and how it relates to the evolution of different kinds of software artifacts, it is not surprising that industry reports existing tools and solutions ineffective, as they do not handle the complexity found in practice. Attempting to mitigate this overall lack of knowledge and to support tool builders with insights on how variability models coevolve with other artifact types, we study a large and complex real-world variant-rich software system: the Linux kernel. Specifically, we extract variability-coevolution patterns capturing changes in the variability model of the Linux kernel with subsequent changes in Makefiles and C source code. From the analysis of the patterns, we report on findings concerning evolution principles found in the kernel, and we reveal deficiencies in existing tools and theory when handling changes captured by our patterns.     

Knowledge transfer,translation and transformation in the work of information technology architects

ContextInformation Technology (IT) architects are the professionals responsible for designing the information systems for an organization. In order to do that, they take into account many aspects and stakeholders, including customers, software developers, the organization’s business, and its current IT infrastructure. Therefore, different aspects influence their work.ObjectiveThis paper presents results of research into how IT architects perform their work in practice and how different aspects are taken into account when an information system is developed. An understanding of IT architects’ activities allows us to better support their work. This paper extends our own previous work (Figueiredo et al., 2012) [30] by discussing aspects of knowledge management and tool support.MethodA qualitative study was conducted using semi-structured interviews for data collection and grounded theory methods (Strauss and Corbin, 1998) [5] for data analysis. Twenty-seven interviews were conducted with twenty-two interviewees from nine different companies through four cycles of data collection and analysis.ResultsCompanies divide IT architecture activities among different roles. Although these roles receive different names in different organizations, all organizations follow a similar pattern based on 3 roles: enterprise, solutions and software architects. These architects perform both the technical activities related to the IT architecture and the social activities regarding the communication and coordination with other stakeholders and among themselves. Furthermore, current tools used by IT architects lack adequate support for all these aspects.ConclusionThe activities of the different IT architects are highly interconnected and have a huge influence in the way the requirements are handled in every phase of the development of an information system. The activities of IT architects are also important for knowledge transfer, translation and transformation, since they receive from and spread information to different groups of stakeholders. We also conclude that they lack appropriate tool support, especially regarding support for their collaborative work.     

Relative importance of evaluation criteria for enterprise systems: a conjoint study

Abstract.  While a large body of research exists on the development and implementation of software, organizations are increasingly acquiring enterprise software packages [e.g. enterprise resource planning (ERP) systems] instead of custom developing their own software applications. To be competitive in the marketplace, software package development firms must manage the three-pronged trade-off between cost, quality and functionality. Surprisingly, prior research has made little attempt to investigate the characteristics of packaged software that influence management information system (MIS) managers' likelihood of recommending purchase. As a result, both the criteria by which MIS managers evaluate prospective packaged systems and the attributes that lead to commercially competitive ERP software products are poorly understood. This paper examines this understudied issue through a conjoint study. We focus on ERP systems, which are among the largest and most complex packaged systems that are purchased by organizations. In a conjoint study, 1008 evaluation decisions based on hypothetical ERP software package profiles were completed by managers in 126 organizations. The study represents the first empirical investigation of the relative importance that managers ascribe to various factors that are believed to be important in evaluating packaged software. The results provide important insights for both organizations that acquire such systems and those that develop them. The results show that functionality, reliability, cost, ease of use and ease of customization are judged to be important criteria, while ease of implementation and vendor reputation were not found to be significant. Functionality and reliability were found to be the most heavily weighted factors. We conclude the paper with a detailed discussion of the results and their implications for software acquisition and development practice.     

Development of service-oriented architectures using model-driven development: A mapping study

ContextModel-Driven Development (MDD) and Service-Oriented Architecture (SOA) are two challenging research areas in software engineering. MDD is about improving software development whilst SOA is a service-based conceptual development style, therefore investigating the available proposals in the literature to use MDD when developing SOA may be insightful. However, no studies have been found with this purpose.ObjectiveThis work aims at assessing the state of the art in MDD for SOA systems. It mainly focuses on: what are the characteristics of MDD approaches that support SOA; what types of SOA are supported; how do they handle non-functional requirements.MethodWe conducted a mapping study following a rigorous protocol. We identified the representative set of venues that should be included in the study. We applied a search string over the set of selected venues. As result, 129 papers were selected and analysed (both frequency analysis and correlation analysis) with respect to the defined classification criteria derived from the research questions. Threats to validity were identified and mitigated whenever possible.ResultsThe analysis allows us to answer the research questions. We highlight: (1) predominance of papers from Europe and written by researchers only; (2) predominance of top-down transformation in software development activities; (3) inexistence of consolidated methods; (4) significant percentage of works without tool support; (5) SOA systems and service compositions more targeted than single services and SOA enterprise systems; (6) limited use of metamodels; (7) very limited use of NFRs; and (8) limited application in real cases.ConclusionThis mapping study does not just provide the state of the art in the topic, but also identifies several issues that deserve investigation in the future, for instance the need of methods for activities other than software development (e.g., migration) or the need of conducting more real case studies.     

Obsolete software requirements

ContextCoping with rapid requirements change is crucial for staying competitive in the software business. Frequently changing customer needs and fierce competition are typical drivers of rapid requirements evolution resulting in requirements obsolescence even before project completion.ObjectiveAlthough the obsolete requirements phenomenon and the implications of not addressing them are known, there is a lack of empirical research dedicated to understanding the nature of obsolete software requirements and their role in requirements management.MethodIn this paper, we report results from an empirical investigation with 219 respondents aimed at investigating the phenomenon of obsolete software requirements.ResultsOur results contain, but are not limited to, defining the phenomenon of obsolete software requirements, investigating how they are handled in industry today and their potential impact.ConclusionWe conclude that obsolete software requirements constitute a significant challenge for companies developing software intensive products, in particular in large projects, and that companies rarely have processes for handling obsolete software requirements. Further, our results call for future research in creating automated methods for obsolete software requirements identification and management, methods that could enable efficient obsolete software requirements management in large projects.     

Organizations’ approaches to blockchain: A critical realist perspective

Organizations face manifold implementation barriers in blockchain adoption. Of particular interest is the pre-adoption phase, where knowledge and attitudes guide organizations’ approaches toward a new technology. This paper examines organizations’ approaches to blockchain through a sensemaking lens to identify how blockchain prototype development is guided by perceived business value of and sentiments toward the technology. Taking a critical realist perspective, we examine divergences between organizations’ approaches toward blockchain adoption, i.e., what they do, and why and how they approach blockchain. We differentiate between four types of approaches and provide recommendations how the pre-adoption phase can be considered in academic analyses.     

A rigorous methodology for specification and verification of business processes

Both specification and verification of business processes are gaining more and more attention in the field. Most of the existing works in the last years are dealing with important, yet very specialized, issues. Among these, we can enumerate compensation constructs to cope with exceptions generated by long running business transactions, fully programmable fault and compensation handling mechanism, web service area, scope-based compensation and shared-labels for synchronization, and so on. The main purpose of this paper is to present a semi-automatized framework to describe and analyse business processes. Business analysts can now use a simple specification language (e.g., BPMN [Obj06]) to describe any type of activity in a company, in a concurrent and modular fashion. The associated programs (e.g., BPDs [Obj06]) have to be executed in an appropriate language (e.g., BPEL4WS [ACD⁺03]). Much more, they have to be confirmed to be sound, via some prescribed (a priori) conditions. We suggest how all the issues can be embedded in a unifying computer tool. We link our work with similar approaches and we justify our particular choices (besides BPMN and BPD): the TLA+ language for expressing the imposed behavioural conditions and Petri Nets ([EB87], [EB88]) to describe an intermediate semantics. In fact, we want to manage in an appropriate way the general relationship diagram (Fig. 1). Examples and case studies are provided. General relationship diagram     

Requirements and constructors for tailoring software processes: a systematic literature review

Organizations developing software-based systems or services often need to tailor process reference models—including product-oriented and project-oriented processes—to meet both their own characteristics and those of their projects. Existing process reference models, however, are often defined in a generic manner. They typically offer only limited mechanisms for adapting processes to the needs of organizational units, project goals, and project environments. This article presents a systematic literature review of peer-reviewed conference and journal articles published between 1990 and 2009. Our aim was both to identify requirements for process-tailoring notation and to analyze those tailoring mechanisms that are currently in existence and that consistently support process tailoring. The results show that the software engineering community has demonstrated an ever-increasing interest in software process tailoring, ranging from the consideration of theoretical proposals regarding how to tailor processes to the scrutiny of practical experiences in organizations. Existing tailoring mechanisms principally permit the modeling of variations of activities, artifacts, or roles by insertion or deletion. Two types of variations have been proposed: the individual modification of process elements and the simultaneous variation of several process elements. Resolving tailoring primarily refers to selecting or deselecting optional elements or to choosing between alternatives. It is sometimes guided by explicitly defined processes and supported by tools or mechanisms from the field of knowledge engineering. The study results show that tailoring notations are not as mature as the industry requires if they are to provide the kind of support for process tailoring that fulfills the requirements identified, i.e., including security policies for the whole process, or carrying out one activity rather than another. A notation must therefore be built, which takes these requirements into consideration in order to permit variant-rich processes representation and use this variability to consistently support process tailoring.     

Incorporating technology in service-oriented i* business models: a case study

In recent years, considerable attention has been paid to enterprise information systems. This interest is motivated by the need for achieving better integration of new technologies (hardware and software) with the business processes of an organization. Business processes have become more and more dependent on technologies because technology has a direct impact on business processes, changing the way they are performed and thus also affecting the way analysts design the software system. However, at the present time, there are still some gaps between the definition of business processes and the technologies used in the organization. In practice, organizations have carried out their business processes using different technologies; however, it is sometimes not possible to determine how technologies are useful in achieving current business goals. This is because business models do not explicitly consider the technologies in the organizational requirements. The goal of this paper is to present a systematic process for integrating business processes and technologies at the conceptual level. To validate our approach, we present a case study that describes the processes of the inventory management department of a public research center.     

Characterizing and evaluating the quality of software process modeling language: Comparison of ten representative model-based languages

Software organizations are very conscious that deployments of well-defined software processes improve software product development and its quality. Over last decade, many Software Process Modeling Languages (SPMLs) have been proposed to describe and manage software processes. However, each one presents advantages and disadvantages. The main challenge for an organization is to choose the best and most suitable SPML to meet its requirements. This paper proposes a Quality Model (QM) which has been defined conforms to QuEF (Quality Evaluation Framework). This QM allows to compare model-based SPMLs and it could be used by organizations to choose the most useful model-based SPML for their particular requirements. This paper also instances our QM to evaluate and compare 10 representative SPMLs of the various alternative approaches (metamodel-level approaches; SPML based on UML and approaches based on standards). Finally, this paper concludes there are many model-based proposals for SPM, but it is very difficult to establish with could be the commitment to follow. Some non-considered aspects until now have been identified (e.g., validation within enterprise environments, friendly support tools, mechanisms to carry out continuous improvement, mechanisms to establish business rules and elements for software process orchestrating).