Catálogo de publicaciones - libros

Software product lines have proven to empower industry to develop a diversity of similar software-intensive systems at lower cost, in shorter time, and with higher quality when compared with the development of single systems. In this chapter, we describe the key differences between software product line engineering and the development of single software systems: the two complementary development processes and the explicitly managed product line variability. Looking ahead, we sketch some applications of the product line variability modeling principles and techniques in non-SPLE settings.

During the last decade, process-aware information systems (PAISs) have become increasingly popular to digitize business processes and to effectively support them at the operational level. In many application domains, however, PAISs will not be accepted by users if rigidity comes with them. Ensuring PAIS robustness, in turn, becomes extremely complicated if high flexibility demands need to be fulfilled. To cope with the dynamic nature of business processes, we developed AristaFlow, a next generation process management technology that enables comprehensive process lifecycle support. In addition to standard process management services, AristaFlow can handle exceptions, change the execution of running business cases on the fly, efficiently deal with uncertainty, and support the evolution of business processes over time. This chapter discusses how AristaFlow assists the various stakeholders of a PAIS to cope with errors and exceptional situations, while still meeting robustness needs. In particular, we focus on new error handling procedures and capabilities utilizing the flexibility provided by ad hoc changes.

Model-based software engineering (MBSE) is used in research and industry for quite a while. After three decades of improving modeling techniques, concepts, and explicit modeling languages as well as understanding the usability and failures of modeling in development projects, this chapter summarizes the principal obstacles, achievements, and failures of MBSE projects from a personal perspective. We consider the use of MBSE as a failure in a development project, if the methodology fails to meet its goals with respect to the particular project. For example, some reasons for failures are as follows: developers initially decide not to use models (negative cost/benefit analysis), decrease in productivity (increase in development time), or decrease in software quality (e.g., decrease in maintainability, understandability, or performance). On the contrary, the use of MBSE in a development project is an achievement, if it succeeds to accomplish all desired goals with respect to the particular project. Besides the aspects mentioned above, this could also be increased analyzability of the system under development due to the introduced high-level abstraction of models.