Dynamic Evolution of Software Processes to Evolve Software Systems During Their Development

A software system, once deployed into its target environment, might need to be modified for various reasons. The reasons might be specific to that software system, such as failures, or, more general, such as changes in the environment in which the software system is embedded. Depending on the reason, a modification might obviously not only be restricted to a particular software system. It might also concern other existing software systems and particularly also software systems under development. The modification of a software system under development is merely a problem of modifying its development process, also called software process. Such modifications generally cannot be automatically carried out by autonomous process support systems due to the complexity inherent in software processes and in the necessary modifications. It usually needs to be guided by a human process manager. A process support system can, however, offer the human process manager certain services to assist in modifying a software process. One of these services is that of decision support

Process-based Software Tweaking with Mobile Agents

We describe an approach based upon software process technology to on-the-fly monitoring, redeployment, reconfiguration, and in general adaptation of distributed software applications, in short 'software tweaking'. We choose the term tweaking to refer to modifications in structure and behavior that can be made to individual components, as well as sets thereof, or the overall target system configuration, such as adding, removing or substituting components, while the system is running and without bringing it down. The goal of software tweaking is manifold: supporting run-time software composition, enforcing adherence to requirements, ensuring uptime and quality of service of mission-critical systems, recovering from and preventing faults, seamless system upgrading, etc. Our approach involves dispatching and coordinating software agents - named Worklets - via a process engine, since successful tweaking of a complex distributed software system often requires the concerted action of multiple agents on multiple components. The software tweaking process must incorporate and decide upon knowledge about the specifications and architecture of the target software, as well as Worklets capabilities. Software tweaking is correlated to a variety of other software processes - such as configuration management, deployment, validation and evolution - and allows to address at run time a number of related concerns that are normally dealt with only at development time

Business modeling in process-oriented organizations for RUP-based software development

Several organizations are nowadays not particularly comfortable with their internal structuring based on a hierarchical arrangement (sub-divided in departments), where collaborators with a limited view of the overall organization perform their activities. Those organizations recognize the need to move to a model where multi-skilled teams run horizontal business processes that cross the organization, and impact suppliers and clients. To develop software systems for any organization, the development process must always be appropriate and controlled. Additionally for organizations who want to migrate to a horizontal business processes view, it is required to model the organizational platform where the organizational processes will run. This necessity is also true when the organization under consideration is a software house. In this chapter, a proposal of a generic framework for process-oriented software houses is presented. The way of managing the process model and the instantiation of their processes with the Rational Unified Process (RUP) disciplines, whenever they are available, or with other kind of processes is recommended as a way to control and define the software development process. To illustrate the usefulness of the proposal, it is presented how the generic reference framework was executed in a real project called “Premium Wage” and shown, in some detail, the created artifacts (which include several UML models) during the development phases following the RUP disciplines, especially the artifacts produced for business modeling.(undefined

First turkish software product line engineering workshop summary

Cataloged from PDF version of article.Software reuse has been a goal of the software community since the early days of software engineering. In this context software product line engineering (SPLE) has gained a broad interest in both academic institutions and industry. This trend can also be observed in Turkey. In the recent years an increasing number of software companies in Turkey have adopted a SPLE approach while others are planning to make the transition. This paper summarizes the results of the First Turkish Software Product Line Engineering Workshop that has been organized in Ankara in June 2012. The primary goal of the workshop was to reflect on the state of practice in SPLE in Turkey. For this five leading SPLE companies in Turkey have shared their experiences in adopting SPLE, and using interactive discussions a research agenda for SPLE in Turkey has been defined. We report both on the experiences from the workshop and the resulting research topics

Analysis of Mobile Business Processes for the Design of Mobile Information Systems

The adoption of mobile technologies into companies frequently follows a technology-driven approach without precise knowledge about the potential benefits that may be realised. Especially in larger organisations with complex business processes, a systematic procedure is required if a verifiable economic benefit is to be created by the use of mobile technologies. Therefore, the term “mobile business process”, as well as requirements for information systems applied in such processes, are defined in this paper. Subsequently, we introduce a procedure for the systematical analysis of the distributed structure of a business process model in order to identify mobile sub-processes. For that purpose, the method Mobile Process Landscaping is used to decompose a process model into different levels of detail. The method aims to manage the complexity and limit the process analysis to the potentially mobile sub-processes from the beginning. The result of the analysis can be used on the one hand as a foundation for the redesign of the business processes and on the other hand for the requirements engineering of mobile information systems. An application of this method is shown by the example of business processes in the insurance industry

Effects of Mobile Business Processes on the Software Process

The adoption of mobile technologies into companies frequently follows a technology-driven approach without precise knowledge about the potential benefits that may be realised. Especially in larger organisations with complex business processes, a systematic procedure is required if a verifiable economic benefit is to be created by the use of mobile technologies. Therefore, the term “mobile business process” is defined in this paper. Subsequently, we introduce a procedure for the systematical analysis of the distributed structure of a business process model in order to identify requirements for software engineering in mobile sub-processes. For that purpose, the method Mobile Process Landscaping is used to decompose a process model into different levels of detail. The method aims to manage the complexity and limit the process analysis to the potentially mobile sub-processes from the beginning. The result of the analysis can be used on the one hand as a foundation for the redesign of the business processes and on the other hand for the requirements engineering of mobile information systems

Goal model integration for tailoring product line development processes

Many companies rely on the promised benefits of product lines, targeting systems between fully custom made software and mass products. Such customized mass products account for a large number of applications automatically derived from a product line. This results in the special importance of product lines for companies with a large part of their product portfolio based on their product line. The success of product line development efforts is highly dependent on tailoring the development process. This paper presents an integrative model of influence factors to tailor product line development processes according to different project needs, organizational goals, individual goals of the developers or constraints of the environment. This model integrates goal models, SPEM models and requirements to tailor development processes

The design and implementation of the VRPML support environment.

Proses pembangunan penslan berkait rapat dengan turutan langkah yang mesti dilakukan oleh jurutera perisian untuk memenuhi matlamat kejuruteraan perisian. Untuk menghasilkan proses yang tepat dan lengkap, proses pembangunan perisian boleh dimodel dan dilari menggunakan bahasa pennodelan (PML) dengan dibantu oleh sistem proses bantuan (PSEE). Software processes relate to the sequences of steps that must be performed by software engineers in order to pursue the goals of software engineering. In order to have an accurate representation and implementation of what the actual steps are, software processes may be modeled and enacted by a process modeling language (PML) and its process support system (called the Process Centered Environments i.e. PSEE)

Archample-Architectural Analysis Approach for Multiple Product Line Engineering

The increased size and complexity of software systems has led to the notion of multiple software product lines (MPLs) in which products are composed from subproducts in separate software product lines. Thus, it is important to identify the proper architectural decomposition of the MPL with respect to the stakeholders' concerns before large organizational resources are committed to the development. Designing MPL architectures is challenging due to the higher level of abstraction and the integration of different product lines. Different architecture analysis approaches have been introduced, but none of these focuses on the evaluation of MPL architectures. We propose the architecture analysis approach for MPL Engineering (Archample), which has been particularly defined for the analysis of MPL architectures. Archample also introduces architectural viewpoints for modeling and documenting MPL and likewise supporting the analysis of the decomposition of an MPL architecture. The approach has been designed and validated within a real industrial context of Aselsan REHI˙S Group (Aselsan REHI˙S), a leading high-technology company in defense systems development in Turkey. © 2014 Elsevier Inc. All rights reserved