ABSTRACT Natural language processing (NLP) offers the potential to automate quality assurance of software requirement specifications. In particular, large‐scale projects involving numerous suppliers can benefit from this improvement. However, due to privacy restrictions especially in highly restrictive industries, the availability of software requirements specification documents for training NLP tools is severely limited. Also, domain‐ and project‐specific vocabulary, as such in the aerospace domain, require specialized models for processing effectively. To provide a sufficient amount of data to train such models, we studied algorithms for the augmentation of textual data. Four algorithms have been investigated by expanding a given set of requirements from the European Space projects generating correct and incorrect requirements. The initial study yielded data of poor quality due to the particularities of the domain‐specific vocabulary, yet laid the foundation for the algorithms' improvement, which, eventually, resulted in an increased set of requirements, which is 20 times the size of the seed set. A complementing experiment demonstrated the usability of augmented requirements to support AI‐based quality assurance of software requirements. Furthermore, a selected improvement of the augmentation algorithms demonstrated notable quality improvements by doubling the number of correctly augmented requirements.

In large-scale projects operated in regulated environments, standard development processes are employed to meet strict compliance demands. Since such processes are usually complex, providing process users with access to their required process, which should be tailored to a project’s needs is a challenging task that requires proper tool support. In this paper, we present a process ecosystem in which software processes are provided as web-based services. We outline the general idea, describe the modeling approach, and we illustrate the concept’s realization using a proof-of-concept case based on a large software process line that is mandatory to use for IT projects in the German public sector. The suitability is evaluated with three experts that valued the improved accessibly and usability of the process and the end-user support tool.

Over the years, a substantial body of knowledge of software process improvement (SPI) was accumulated that, among other things, includes numerous success factors that companies should consider when conducting improvement activities. The number of success factors is large and quite often, multiple success factors with similar names and descriptions are available to address a specific phenomenon. This raises the question whether all the success factors are unique and, if not, which ones are actually the same. In this paper, we aim to structure the body of knowledge on success factors in SPI. We conducted a systematic literature review on 103 publications that mention 1.320 success factors. A multi-staged manual and AI-supported analysis reduced the number of success factors to 124, which we categorize into 42 general success factor classes. For 20 of these general success factor classes, we observed a stable number of publications over a period of almost 30 years that, however, show only few success factors constantly studied and re-discovered. A high number of synonyms shows that this area of SPI needs consolidation for which we lay the foundation by providing a big picture and identifying the most relevant success factors as a starting point.

With the emergence of agile software development methods, new approaches for determining agile maturity have become necessary. Other than for traditional maturity and capability models like CMMI and ISO/IEC 15504, the field of agile maturity models is not yet settled. Even worse, a common understanding regarding agility in general and the levels of agility in particular is missing. The paper at hand aims to shed light on the field of agile maturity models with a particular focus on maturity levels, their definition, and their evaluation and computation. We conducted a systematic literature review to extract maturity levels and provide an initial harmonization of the levels found. Our findings from analyzing 19 agile maturity models show that there is yet no agreement with regard to the maturity levels. In total, 69 maturity levels have been analyzed for harmonization opportunities. Two major dimensions of maturity levels of agile maturity models could be identified: (1) team-related and (2) general maturity, which is comparable to standard approaches. However, the procedures to assess organizations and processes, if at all present, are to a large extent focused on persons and their personal opinion, which paves the way for future research, e.g., in terms of developing measurement systems for assessing agile maturity.

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Abstract Hardly any software development process is used as prescribed by authors or standards. Regardless of company size or industry sector, a majority of project teams and companies use hybrid development methods (short: hybrid methods) that combine different development methods and practices. Even though such hybrid methods are highly individualized, a common understanding of how to systematically construct synergetic practices is missing. In this article, we make a first step towards a statistical construction procedure for hybrid methods. Grounded in 1467 data points from a large‐scale practitioner survey, we study the question: What are hybrid methods made of and how can they be systematically constructed? Our findings show that only eight methods and few practices build the core of modern software development. Using an 85% agreement level in the participants' selections, we provide examples illustrating how hybrid methods can be characterized by the practices they are made of. Furthermore, using this characterization, we develop an initial construction procedure, which allows for defining a method frame and enriching it incrementally to devise a hybrid method using ranked sets of practice.

Abstract Software is an integrated part of new features within the automotive sector, car manufacturers, the Hersteller Initiative Software (HIS) consortium defined metrics to determine software quality. Yet, problems with assigning metrics to quality attributes often occur in practice. The specified boundary values lead to discussions between contractors and clients as different standards and metric sets are used. This paper studies metrics used in the automotive sector and the quality attributes they address. The HIS, ISO/IEC 25010:2011, and ISO/IEC 26262:2018 are utilized to draw a big picture illustrating (i) which metrics and boundary values are reported in literature, (ii) how the metrics match the standards, (iii) which quality attributes are addressed, and (iv) how the metrics are supported by tools. Our findings from analyzing 38 papers include a catalog of 112 metrics of which 17 define boundary values and 48 are supported by tools. Most of the metrics are concerned with source code, are generic, and not specifically designed for automotive software development. We conclude that many metrics exist, but a clear definition of the metrics' context, notably regarding the construction of flexible and efficient measurement suites, is missing.

Selecting a suitable development method for a specific project context is one of the most challenging activities in process design. Every project is unique and, thus, many context factors have to be considered. Recent research took some initial steps towards statistically constructing hybrid development methods, yet, paid little attention to the peculiarities of context factors influencing method and practice selection. In this paper, we utilize exploratory factor analysis and logistic regression analysis to learn such context factors and to identify methods that are correlated with these factors. Our analysis is based on 829 data points from the HELENA dataset. We provide five base clusters of methods consisting of up to 10 methods that lay the foundation for devising hybrid development methods. The analysis of the five clusters using trained models reveals only a few context factors, e.g., project/product size and target application domain, that seem to significantly influence the selection of methods. An extended descriptive analysis of these practices in the context of the identified method clusters also suggests a consolidation of the relevant practice sets used in specific project contexts.

Abstract Context Software testing is an important and costly software engineering activity in the industry. Despite the efforts of the software testing research community in the last several decades, various studies show that still many practitioners in the industry report challenges in their software testing tasks. Objective To shed light on industry's challenges in software testing, we characterize and synthesize the challenges reported by practitioners. Such concrete challenges can then be used for a variety of purposes, eg, research collaborations between industry and academia. Method Our empirical research method is opinion survey. By designing an online survey, we solicited practitioners' opinions about their challenges in different testing activities. Our dataset includes data from 72 practitioners from eight different countries. Results Our results show that test management and test automation are considered the most challenging among all testing activities by practitioners. Our results also include a set of 104 concrete challenges in software testing that may need further investigations by the research community. Conclusion We conclude that the focal points of industrial work and academic research in software testing differ. Furthermore, the paper at hand provides valuable insights concerning practitioners' “pain” points and, thus, provides researchers with a source of important research topics of high practical relevance.

Software process improvement (SPI) is around for decades, but it is a critically discussed topic. In several waves, different aspects of SPI have been discussed in the past, e.g., large-scale company-level SPI programs, maturity models, success factors, and in-project SPI. It is hard to find new streams or a consensus in the community, but there is a trend coming along with agile and lean software development. Apparently, practitioners reject extensive and prescriptive maturity models and move towards smaller, faster and continuous project-integrated SPI. Based on data from two survey studies conducted in Germany (2012) and Europe (2016), we analyze the process customization for projects and practices for implementing SPI in the participating companies. Our findings indicate that, even in regulated industry sectors, companies increasingly adopt in-project SPI activities, primarily with the goal to continuously optimize specific processes. Therefore, with this paper, we want to stimulate a discussion on how to evolve traditional SPI towards a continuous learning environment.

Among the multitude of software development processes available, hardly any is used by the book. Regardless of company size or industry sector, a majority of project teams and companies use customized processes that combine different development methods--so-called hybrid development methods. Even though such hybrid development methods are highly individualized, a common understanding of how to systematically construct synergetic practices is missing. In this paper, we make a first step towards devising such guidelines. Grounded in 1,467 data points from a large-scale online survey among practitioners, we study the current state of practice in process use to answer the question: What are hybrid development methods made of? Our findings reveal that only eight methods and few practices build the core of modern software development. This small set allows for statistically constructing hybrid development methods. Using an 85% agreement level in the participants' selections, we provide two examples illustrating how hybrid development methods are characterized by the practices they are made of. Our evidence-based analysis approach lays the foundation for devising hybrid development methods.

Abstract The emergence of agile methods and practices has not only changed the development processes but might also have affected how companies conduct software process improvement (SPI). Through a set of complementary studies, we aim to understand how SPI has changed in times of agile software development. Specifically, we aim (a) to identify and characterize the set of publications that connect elements of agility to SPI, (b) to explore to which extent agile methods/practices have been used in the context of SPI, and (c) to understand whether the topics addressed in the literature are relevant and useful for industry professionals. To study these questions, we conducted an in‐depth analysis of the literature identified in a previous mapping study, an interview study, and an analysis of the responses given by industry professionals to SPI‐related questions stemming from an independently conducted survey study. Regarding the first question, we identified 55 publications that focus on both SPI and agility of which 48 present and discuss how agile methods/practices are used to steer SPI initiatives. Regarding the second question, we found that the two most frequently mentioned agile methods in the context of SPI are Scrum and Extreme Programming (XP), while the most frequently mentioned agile practices are integrate often, test‐first, daily meeting, pair programming, retrospective, on‐site customer, and product backlog. Regarding the third question, we found that a majority of the interviewed and surveyed industry professionals see SPI as a continuous activity. They agree with the agile SPI literature that agile methods/practices play an important role in SPI activities but that the importance given to specific agile methods/practices does not always coincide with the frequency with which these methods/practices are mentioned in the literature.

Abstract The International Conference on Software and System Processes (ICSSP) provides a leading forum for the exchange of research outcomes and industrial best practices in process development from software and systems disciplines. ICSSP 2018 was held in Gothenburg, Sweden, May 26 to 27, 2018, colocated with the 40th International Conference on Software Engineering (ICSE). The theme of ICSSP 2018 was studying “Demands on Processes, Processes on Demand” by recognizing the demands on processes that include the need for both well‐developed plans and incremental deliveries (agile and hybrid processes), utilization of increased automation (model‐based engineering and DevOps), higher degrees of customer collaboration, comprehensive analysis of existing products for reuse (open source and COTS), and performance requirements of enterprise‐level architectures. This special issue includes the revised and extended versions of the five highest ranked full research papers and industry experience papers of ICSSP 2018, including the two award‐winning papers.

Even though agile methods have been flourishing in the last decades, their implementation in (globally) distributed arrangements still present hard challenges. Due to this tension, practices are either modified or added to compensate with the additional control required by the setup. In this paper, we present a case study about a company that managed to incrementally design a process that does not compromise the foundations of the agile philosophy by embracing the characteristics of distributed development. We show how a virtual work environment has been crafted by continuously improving practices and carefully selecting technologies to allow each team member to fully participate regardless of the actual physical location. Aware of the single nature limitation of the reported case, we present extensive information to frame the context allowing meaningful comparisons by researchers and providing concrete examples for practitioners.

Context: Organizations increasingly develop software in a distributed manner. The Cloud provides an environment to create and maintain software-based products and services. Currently, it is unknown which software processes are suited for Cloud-based development and what their effects in specific contexts are. Objective: We aim at better understanding the software process applied to distributed software development using the Cloud as development environment. We further aim at providing an instrument, which helps project managers comparing different solution approaches and to adapt team processes to improve future project activities and outcomes. Method: We provide a simulation model, which helps analyzing different project parameters and their impact on projects performed in the Cloud. To evaluate the simulation model, we conduct different analyses using a Scrumban process and data from a project executed in Finland and Spain. An extra adaptation of the simulation model for Scrum and Kanban was used to evaluate the suitability of the simulation model to cover further process models. Results: A comparison of the real project data with the results obtained from the different simulation runs shows the simulation producing results close to the real data, and we could successfully replicate a distributed software project. Furthermore, we could show that the simulation model is suitable to address further process models. Conclusion: The simulator helps reproducing activities, developers, and events in the project, and it helps analyzing potential tradeoffs, e.g., regarding throughput, total time, project size, team size and work-in-progress limits. Furthermore, the simulation model supports project managers selecting the most suitable planning alternative thus supporting decision-making processes.

The level of industry-academia collaboration (IAC) in software engineering in general and in software testing in particular is quite low. Many researchers and practitioners are not collaborating with the "other side" to solve industrial problems. To shed light on the above issue and to characterize precisely what industry wants from academia in software testing, we solicited practitioners' opinions on their challenges in different testing activities and also the particularly relevant topics that they want the research community to work on. This short paper aims to draw the community's attention to the important issue of strengthening IAC with the hope of more IAC in software testing in the areas of most importance to the industry.

Distributed software engineering and agility are strongly pushing on today's software industry. Due to inherent incompatibilities, for years, studying Scrum and its application in distributed setups has been subject to theoretical and applied research, and an increasing body of knowledge reports insights into this combination. Through a systematic literature review, this paper contributes a collection of experiences on the application of Scrum to global software engineering (GSE). In total, we identified 40 challenges in 19 categories practitioners face when using Scrum in GSE. Among the challenges, scaling Scrum to GSE and adopting practices accordingly are the most frequently named. Our findings also show that most solution proposals aim at modifying elements of the Scrum core processes. We thus conclude that, even though Scrum allows for extensive modification, Scrum itself represents a barrier for global software engineering, and development teams have to customize Scrum properly to benefit from agile software development in GSE.

A software process is the game plan to organize project teams and run projects. Yet, it still is a challenge to select the appropriate development approach for the respective context. A multitude of development approaches compete for the users' favor, but there is no silver bullet serving all possible setups. Moreover, recent research as well as experience from practice shows companies utilizing different development approaches to assemble the best-fitting approach for the respective company: a more traditional process provides the basic framework to serve the organization, while project teams embody this framework with more agile (and/or lean) practices to keep their flexibility. The first HELENA workshop aims to bring together the community to discuss recent findings and to steer future work.

Software and system development faces numerous challenges of rapidly changing markets. To address such challenges, companies and projects design and adopt specific development approaches by combining well-structured comprehensive methods and flexible agile practices. Yet, the number of methods and practices is large, and available studies argue that the actual process composition is carried out in a fairly ad-hoc manner. The present paper reports on a survey on hybrid software development approaches. We study which approaches are used in practice, how different approaches are combined, and what contextual factors influence the use and combination of hybrid software development approaches. Our results from 69 study participants show a variety of development approaches used and combined in practice. We show that most combinations follow a pattern in which a traditional process model serves as framework in which several fine-grained (agile) practices are plugged in. We further show that hybrid software development approaches are independent from the company size and external triggers. We conclude that such approaches are the results of a natural process evolution, which is mainly driven by experience, learning, and pragmatism.

Organizations increasingly develop software in a distributed manner. The Cloud provides an environment to create and maintain software-based products and services. Currently, it is widely unknown which software processes are suited for Cloud-based development and what their effects in specific contexts are. This paper presents a process simulation to study distributed development in the Cloud. We contribute a simulation model, which helps analyzing different project parameters and their impact on projects carried out in the Cloud. The simulator helps reproducing activities, developers, issues and events in the project, and it generates statistics, e.g., on throughput, total time, and lead and cycle time. The aim of this simulation model is thus to analyze the tradeoffs regarding throughput, total time, project size, and team size. Furthermore, the modified simulation model aims to help project managers select the most suitable planning alternative. Based on observed projects in Finland and Spain, we simulated a distributed project using artificial and real data. Particularly, we studied the variables project size, team size, throughput, and total project duration. A comparison of the real project data with the results obtained from the simulation shows the simulation producing results close to the real data, and we could successfully replicate a distributed software project. By improving the understanding of distributed development processes, our simulation model thus supports project managers in their decision-making.

Journal of Software: Evolution and ProcessVolume 29, Issue 11 e1869 SPECIAL ISSUE PAPER ICSSP 2016 – Special Issue Introduction Marco Kuhrmann, Corresponding Author Marco Kuhrmann [email protected] orcid.org/0000-0001-6101-8931 Clausthal University of Technology, Goslar, Germany Correspondence Clausthal University of Technology, Institute for Applied Software Systems Engineering, Wallstraße 6, 38640 Goslar, Germany. Email: [email protected] for more papers by this authorRory V. O'Connor, Rory V. O'Connor orcid.org/0000-0001-9253-0313 Dublin City University, Dublin, IrelandSearch for more papers by this authorDewayne E. Perry, Dewayne E. Perry University of Texas, Austin, TX, U.S.A.Search for more papers by this authorDavid Raffo, David Raffo Portland State University, Portland, OR, U.S.A.Search for more papers by this author Marco Kuhrmann, Corresponding Author Marco Kuhrmann [email protected] orcid.org/0000-0001-6101-8931 Clausthal University of Technology, Goslar, Germany Correspondence Clausthal University of Technology, Institute for Applied Software Systems Engineering, Wallstraße 6, 38640 Goslar, Germany. Email: [email protected] for more papers by this authorRory V. O'Connor, Rory V. O'Connor orcid.org/0000-0001-9253-0313 Dublin City University, Dublin, IrelandSearch for more papers by this authorDewayne E. Perry, Dewayne E. Perry University of Texas, Austin, TX, U.S.A.Search for more papers by this authorDavid Raffo, David Raffo Portland State University, Portland, OR, U.S.A.Search for more papers by this author First published: 08 November 2017 https://doi.org/10.1002/smr.1869Read the full textAboutPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Volume29, Issue11Special Issue: Process in Action: The Best Papers from The International Conference on Software and Systems Process 2016November 2017e1869 RelatedInformation

Background: Even though a number of tools are reported to be used by researchers undertaking systematic reviews, important shortages are still reported revealing how such solutions are unable to satisfy current needs. Method: Two research groups independently provided a design for a tool supporting systematic reviews. The resulting tools were assessed against the feature lists provided by prior research. Results: After presenting an overview of the tools and the core design decisions taken, we provide a feature analysis and a discussion regarding selected challenges deemed crucial to provide a proper tool support. Conclusions: Although the designed solutions do not yet support the entire systematic review process, their architecture has been designed to be flexible and extendable. After highlighting the difficulties of developing appropriate tools, we call for action: developing tools to support systematic reviews is a community project.

Mobile robots are advanced systems that often need to operate in unstructured environments, which increases software complexity. Many components are key to the overall reliability and safety of a robot, yet reducing the risk of errors by making the software resilient is both complicated and expensive. A commercially successful robot has to remain safe while providing as much as possible from the functionality required; even in the presence of partial failures. In this paper, we propose a flexible approach to improve the reliability of existing robot software, which enables a wide range of strategies for graceful degradation in the presence of partial failures. We use standard virtualization techniques as a means to encapsulate the safety-critical parts and to separate these from the non-critical parts of the system. An automatically generated runtime monitoring component realizes a fast switching between different implementations of the non-critical parts of the system to ensure continuous service delivery even in partial failure situations. We present the overall architecture and insights into a reference implementation, and we demonstrate our approach by simulating software failures for a commercial mobile robot.

Mobile robots often use a distributed architecture in which software components are deployed to heterogeneous hardware modules. Ensuring the consistency with the designed architecture is a complex task, notably if functional safety requirements have to be fulfilled. We propose to use a domain-specific language to specify those requirements and to allow for generating a safety-enforcing layer of code, which is deployed to the robot. The paper at hand reports experiences in practically applying code generation to mobile robots. For two cases, we discuss how we addressed challenges, e.g., regarding weaving code generation into proprietary development environments and testing of manually written code. We find that a DSL based on the same conceptual model can be used across different kinds of hardware modules, but a significant adaptation effort is required in practical scenarios involving different kinds of hardware.

Professional software products and IT systems and services today are developed mostly by globally distributed teams, projects, and companies. Successfully orchestrating Global Software Engineering (GSE) has become the major success factor both for organizations and practitioners. Yet, more than a half of all distributed projects does not achieve the intended objectives and is canceled. This paper summarizes experiences from academia and industry in a way to facilitate knowledge and technology transfer. It is based on an evaluation of 10 years of research, and industry collaboration and experience reported at the IEEE International Conference on Software Engineering (ICGSE) series. The outcomes of our analysis show GSE as a field highly attached to industry and, thus, a considerable share of ICGSE papers address the transfer of Software Engineering concepts and solutions to the global stage. We found collaboration and teams, processes and organization, sourcing and supplier management, and success factors to be the topics gaining the most interest of researchers and practitioners. Beyond the analysis of the past conferences, we also look at current trends in GSE to motivate further research and industrial collaboration.

For decades, Software Process Improvement (SPI) programs have been implemented, inter alia, to improve quality and speed of software development. To set up, guide, and carry out SPI projects, and to measure SPI state, impact, and success, a multitude of different SPI approaches and considerable experience are available. SPI addresses many aspects ranging from individual developer skills to entire organizations. It comprises for instance the optimization of specific activities in the software lifecycle as well as the creation of organization awareness and project culture. In the course of conducting a systematic mapping study on the state-of-the-art in SPI from a general perspective, we observed Global Software Engineering (GSE) becoming a topic of interest in recent years. Therefore, in this paper, we provide a detailed investigation of those papers from the overall systematic mapping study that were classified as addressing SPI in the context of GSE. From the main study's result set, a set of 30 papers dealing with GSE was selected for an in-depth analysis using the systematic review instrument to study the contributions and to develop an initial picture of how GSE is considered from the perspective of SPI. Our findings show the analyzed papers delivering a substantial discussion of cultural models and how such models can be used to better address and align SPI programs with multi-national environments. Furthermore, experience is shared discussing how agile approaches can be implemented in companies working at the global scale. Finally, success factors and barriers are studied to help companies implementing SPI in a GSE context.

Abstract Software process lines provide a systematic approach to develop and manage software processes. It defines a reference process containing general process assets, whereas a well‐defined customization approach allows process engineers to create new process variants, for example, by extending or modifying process assets. Variability operations are an instrument to realize flexibility by explicitly declaring required modifications, which are applied to create a procedurally generated company‐specific process. However, little is known about which variability operations are suitable in practice. In this article, we present a study on the feasibility of variability operations to support the development of software process lines in the context of the V‐Modell XT. We analyze which variability operations are defined and practically used. We provide an initial catalog of variability operations as an improvement proposal for other process models. Our findings show that 69 variability operation types are defined across several metamodel versions of which, however, 25 remain unused. The found variability operations allow for systematically modifying the content of process model elements and the process documentation, and they allow for altering the structure of a process model and its description. Furthermore, we also find that variability operations can help process engineers to compensate process metamodel evolution. Copyright © 2015 John Wiley & Sons, Ltd.

International audience

Context: Software processes evolve over time and several approaches were proposed to support the required flexibility. Yet, little is known whether these approaches sufficiently support the development of large software processes. A software process line helps to systematically develop and manage families of processes and, as part of this, variability operations provide means to modify and reuse pre-defined process assets. Objective: Our goal is to evaluate the feasibility of variability operations to support the development of flexible software process lines. Method: We conducted a longitudinal study in which we studied 5 variants of the V-Modell XT process line for 2 years. Results: Our results show the variability operation instrument feasible in practice. We analyzed 616 operation exemplars addressing various customization scenarios, and we found 87 different operation types contributed by 3 metamodel variants developed by different teams in different contexts. Conclusions: Although variability operations are only one instrument among others, our results suggest this instrument useful to implement variability in real-life software process lines.

The speed of innovation and the global allocation of resources to accelerate development or to reduce cost put pressure on the software industry. In the global competition, especially so-called high-price countries have to present arguments why the higher development cost is justified and what makes these countries an attractive host for software companies. Often, high-quality engineering and excellent quality of products, e.g., Machinery and equipment, are mentioned. Yet, the question is: Can such arguments be also found for the software industry? We aim at investigating the degree of professionalism and systematization of software development to draw a map of strengths and weaknesses. To this end, we conducted as a first step an exploratory survey in Germany, presented in this paper. In this survey, we focused on the perceived importance of the two general software engineering process areas project- and quality management and their implementation in practice. So far, our results suggest that the necessity for a systematic software development is well recognized, while software development still follows an ad-hoc rather than a systematized style. Our results provide initial findings, which we finally use to elaborate a set of working hypotheses. Those hypotheses allow to steer the adaptation of our instrument in the future to eventually facilitate replications toward a more comprehensive theory on systematic globally distributed software development in practice.

A growing number of companies are discovering that their software development processes must be in compliance with some form of regulation. This is particularly so when it comes to safety-critical or business-critical systems such as Automotive Software, Robotics, Medical Devices or Finan- cial Management systems. These regulations aect the soft- ware development process itself in various forms. Further- more, much attention is being given to ways of improving the eciency of businesses, for example, by adopting lean principles. This raises the question for how to adopt lean principles for software development within a regulated envi- ronment? This poster presents the results of our empirical research into lean and regulated software development. Built from a combination of data sources, we have developed a conceptual framework comprising ve primary components. In addition the relationships they have with both the central focus of the framework (the situated software development practices) and with each other are indicated.

Software process improvement (SPI) is around for decades: frameworks are proposed, success factors are studied, and experiences have been reported. However, the sheer mass of concepts, approaches, and standards published over the years overwhelms practitioners as well as researchers. What is out there? Are there new emerging approaches? What are open issues? Still, we struggle to answer the question for what is the current state of SPI and related research? In this paper, we present initial results from a systematic mapping study to shed light on the field of SPI and to draw conclusions for future research directions. An analysis of 635 publications draws a big picture of SPI-related research of the past 25 years. Our study shows a high number of solution proposals, experience reports, and secondary studies, but only few theories. In particular, standard SPI models like CMMI and ISO/IEC 15504 are analyzed, enhanced, and evaluated for applicability, whereas these standards are critically discussed from the perspective of SPI in small-to-medium-sized companies, which leads to new specialized frameworks. Furthermore, we find a growing interest in success factors to aid companies in conducting SPI.

To overcome shortcomings associated with software process improvement (SPI), we previously recommended that process engineers focus on the artifacts to be developed in SPI projects. These artifacts should define desired outcomes, rather than specific methods. During this prior research, we developed a model for Artifact-based Software Process Improvement & Management (ArSPI). We are now carrying out studies to confirm our claims that ArSPI will provide benefits such as quality assurance. In this paper, we report on an experimental setting in which we developed and analyzed a strategy to use artifact models to direct process model improvement. We analyzed a process specification, the realized model, and the generated electronic process guide. We used ArSPI v0.9 as our process model and the Capability Maturity Model Integration (CMMI) as an external reference to provide a set of overall improvement goals. We propose an effective approach to analyze and improve a process model. In addition, the analysis revealed issues with ArSPI realization, which will be corrected in the next major release.

Structured approaches are beneficial for successful software process improvement (SPI). However, process engineers often struggle with standardized SPI methods, such as capability maturity model integration (CMMI) or International Organization for Standardization (ISO) 15504, and complain about too generic or voluminous approaches or methods that are alien to the organizations in which SPI is conducted. Therefore, process engineers need to customize existing SPI models or develop new approaches for company-specific SPI programs. While conducting SPI in the context of the German V-Modell XT, we faced the need to develop a new method for artifact-based SPI. In the process, we found that the construction procedures of SPI models are barely documented, and thus, their successful adaptation solely depends on the process engineers' expertise. With this article, we aim to address this lack of support and provide a structured reflection on our experiences from creating and adopting the Artifact-based Software Process Improvement & Management (ArSPI) model. We present the steps of the construction procedure, the validation, and the dissemination of the model. Furthermore, we detail on the applied methods, the design decisions, and the challenges encountered. By providing a reference procedure and tested methods, we support process engineers with the creation and adoption of SPI approaches. Copyright © 2015 John Wiley & Sons, Ltd.

Not all incoming students are sufficiently well endowed with those base competencies (such as self organization, analytical thinking or communication skills) that are prerequisite for acquiring complex new knowledge as well as coping with the study process itself. As lecturers, we have to be aware of our incoming students' base competency profile, in order to pick them up where they are and help them develop whatever they need to study successfully. To investigate the students' initial skills regarding their base competencies, we developed a self-assessment focusing on selected self competencies, practical and cognitive skills as well as social competencies that are crucial to study computer science or related topics. In this paper, we present our assessment approach and its design. An initial evaluation in which 320 students were involved indicates that deficits in base competencies can be made tangible for students. Based on the deficits we identified, we are going to optimize our courses to meet freshmen students' needs in a better way.

The organization of projects with distributed teams is a demanding task for every project manager. Requirements need to be collected, documented, and discussed, and the resulting tasks must be distributed to the responsible sites. These activities require an efficient and continuous communication. Furthermore, it is necessary to monitor a project and to track its progress from a management perspective. As a solution, we opt for a monitoring strategy that is based on the project artifacts and corresponding reports. For this, we defined in a previous work a generic artifact model for agile methods to enable seamless communication and data exchange between projects and teams. In this paper, we present a concrete instance aiming at providing the backbone of the information and data exchange subsystem of a SaaS-based collaborative project management and governance software for distributed software development. We present the artifact model, give insights into its development, and discuss its feasibility. Our findings show that while the previously defined reference model adequately reflects basic concepts and thus allows for coupling distributed projects, we need to refine the artifact model to emphasize project management/governance and its implementation in tools.

It is widely accepted that the one size fits all process does not exist. Software processes need to be tailored according to the respective context of companies and projects. However, tailoring a software process often remains a mystery. What is the actual context? What are the parameters to adjust a process? What are the implications of tailoring criteria? A systematic process tailoring requires the ability to anticipate needed flexibility early in the process design process, and to express this in a process modeling language. In this paper, we discuss the design of process tailoring models, which we consider crucial for the design and, eventually, the application of flexible software processes. We advocate for a constructive metamodel-based approach to improve process tailoring.

When it comes to software process improvement (SPI), process engineers look for SPI methods to support process analysis, design, realization, deployment, and management. Although a number of different SPI methods and models exist, process engineers tend to view these as too generic, too large, or a poor fit for the organization in which SPI is conducted. A strategy to overcome these shortcomings is to concentrate on the artifacts, which precisely define the desired outcomes, rather than on specific methods. In this paper, we present the Artifact-based Software Process Improvement & Management (ArSPI) model that provides a unified perspective on SPI and company-wide software process management (SPM), the required key artifacts, and the life cycle models. ArSPI is shown to be of practical support to industry who called for a practical way to define the interfaces between SPI projects. This paper concludes with an example of how ArSPI paved the way for several organizations through applying the model in real-world SPI-projects.

Software process lines provide a systematic approach to construct and manage software processes. A process line defines a reference process containing general process assets, whereas a well-defined customization approach allows process engineers to create new process variants by, e.g., extending or altering process assets. Variability operations are a powerful instrument to realize a process line. However, little is known about which variability operations are suitable in practice. In this paper, we present a study on the feasibility of variability operations to support process lines in the context of the German V-Modell XT. We analyze which variability operations were defined and used to which extent, and we provide a catalog of variability operations as an improvement proposal for other process models. Our findings show 69 variability operations defined across several metamodel versions of which 25 remain unused. Furthermore, we also find that variability operations can help process engineers to compensate process metamodel evolution.

As an approach to develop suitable development processes for software projects, Software Process Selection, Tailoring and Composition (SP-STC) attract lots of attention from both industry and academia. However, without effective guidelines, how to do SP-STC often remains a mystery. This special panel aims to 1) initiate a discussion on the current research status of SP-STC, 2) identify main challenges of SP-STC and possible solutions, and 3) work out a research agenda for future work.

Software processes have become inherently complex to cope with the various situations we face in project environments. In response, the research area of method engineering arose in the 1990s aiming at the systematization of process construction and application. Although the research area has gained much attention and offered a plethora of contributions so far, we still have little knowledge about which basic concepts are finally established and what their feasibility is. To overcome this shortcoming, we need a systematic investigation of the publication flora in method engineering. To reach this aim, we contribute a systematic mapping study and investigate, inter alia, which contributions were published over time and which research type facet they address to distill a common understanding about available method engineering concepts and their maturity. On the basis of the review of 83 publications, our results show that even if a high number of contributions is available, most of those contributions only repeat and discuss formerly introduced concepts, whereas reports on empirically sound evidence on the feasibility are still missing. Although the research area constitutes a many contributions, yet missing are a common understanding of method engineering and empirically sound investigations that would allow for practical application and experience extraction. Copyright © 2014 John Wiley & Sons, Ltd.

Context: Software processes have become inherently complex to cope with the various situations we face in industrial project environments. In response to this problem, the research area of Method Engineering arose in the 1990s aiming at the systematization of process construction. Objective: Although the research area has gained much attention and offered a plethora of contributions so far, we still have little knowledge about the feasibility of Method Engineering. To overcome this shortcoming, necessary is a systematic investigation of the respective publication flora. Method: We conduct a systematic mapping study and investigate, inter alia, which contributions were made over time and which research type facet they address to distill a common understanding of the state-of-the-art. Results: Based on the review of 64 publications, our results show that most of those contributions only repeat and discuss formerly introduced concepts, whereas empirically sound evidence on the feasibility of Method Engineering, is still missing. Conclusion: Although the research area constitutes many contributions, yet missing are empirically sound investigations that would allow for practical application and experience extraction.

Much effort has been spent to investigate the organization of distributed teams and their collaboration patterns. It is, however, not fully understood to which extent and how agile software processes are feasible to support distributed software projects. Practices and challenges that arise from the demands for communication are often in scope of current research. Still, it remains unclear what is necessary to monitor a project and to track its progress from a management perspective. A solution is to monitor projects and their progress on basis of the current quality of the created artifacts according to a given reference model that defines the artifacts and their dependencies. In this paper, we present an artifact model for agile methods that results from of a systematic literature review. The contribution serves as an empirically grounded definition of process interfaces to coordinate projects and to define exchanged artifacts while abstracting from the diverse local software processes.

Most university curricula consider software processes to be on the fringes of software engineering (SE). Students are told there exists a plethora of software processes ranging from RUP over V-shaped processes to agile methods. Furthermore, the usual students' programming tasks are of a size that either one student or a small group of students can manage the work. Comprehensive processes being essential for large companies in terms of reflecting the organization structure, coordinating teams, or interfaces to business processes such as contracting or sales, are complex and hard to teach in a lecture, and, therefore, often out of scope. We experienced tutorials on using Java or C#, or on developing applications for the iPhone to gather more attention by students, simply speaking, as these are more fun for them. So, why should students spend their time in software processes? From our experiences and the discussions with a variety of industrial partners, we learned that students often face trouble when taking their first “real” jobs, even if the company is organized in a lean or agile shape. Therefore, we propose to include software processes more explicitly into the SE curricula. We designed and implemented a course at Master's level in which students learn why software processes are necessary, and how they can be analyzed, designed, implemented, and continuously improved. In this paper, we present our course's structure, its goals, and corresponding teaching methods. We evaluate the course and further discuss our experiences so that lecturers and researchers can directly use our lessons learned in their own curricula.

Independently from which software process was selected for a company or a project, the selected software process usually cannot be applied without any customization. Although the need to tailor a software process to specific project requirements seems to be widely accepted and unquestioned, the way of doing the tailoring remains unclear and is, therefore, often left to the expertise of process engineers or project managers. What are the criteria to be applied in the tailoring? What are dependencies between different criteria and how should certain criteria influence the software process? In this paper we investigate concrete tailoring criteria for the tailoring of software processes. To this end, we present a collection of 49 tailoring criteria as the outcomes of a systematic literature review. We further analyze the impact of the discovered tailoring criteria by relating them to a set of 20 exemplary tailoring actions, which affect the project-specific software process. Our outcomes show that the factors influencing the tailoring are well understood, however, the consequences of the criteria remain abstract and need to be interpreted on a project-per-project basis.

A software process metamodel (SPMM) defines a language to describe concrete software processes in a structured manner. Although agile methods gained much attention in recent years, we still need to provide process engineers with adequate tools to design, implement, publish and deploy, and manage comprehensive software processes. In response to this need, several SPMMs have been developed. It remains, however, unclear, which of those SPMMs are disseminated to which extent. In this paper, we contribute first results of a study on the state-of-the-art in the systematic development of software processes using standardized SPMMs and their corresponding infrastructure. Our results show that only a few documented standards exist and, furthermore, that among those standards only two are disseminated into practice. We focus on those standardized SPMMs, show their process ecosystem, and sketch a first picture on the state-of-the-art in SPMM-based software process develop- ment in order to foster discussions on further problem-driven research.

Background: Little is yet known about how to qualitatively analyse development processes to steer their further optimisation. Thereby, companies are often left to the expertise of third parties when performing such an analysis. Aim: We aim at elaborating a way of empirically analysing development processes on basis of 9 empirical studies we performed at our research group. Method: We analyse 9 empirical studies for commonalities in their research objectives, research methodologies, cases, and methods used to infer a set of research methodology patterns. Results: We discover and discuss three methodology patterns, which we embed into a first experience-based guideline to conduct qualitative analyses of development processes. Conclusion: Our guideline is inferred from a series of successful studies. However, since qualitative analyses always will depend on many aspects that cannot be standardised, we lay with this contribution a first, but fundamental step to be further discussed, evaluated, and extended.

In practice, more and more software development projects are distributed, ranging from partly distributed teams to global projects with each stakeholder located differently. Teaching actual practice in software engineering at university needs a proper mixture of theory and practice. But setting up practical exercises for global software engineering is hard, because students have to cooperate across different locations and situations reflecting the teaching intentions have to be provoked explicitly. This paper presents the concepts behind our common teaching environment for global software engineering - the GloSELab. It describes the experiences on setting up a distributed course and reports our teaching intentions based on each universities main focus: project management, requirements engineering & quality assurance, architecture, and implementation. Furthermore, we discuss our setup - a stage-gate process, where each location takes care of a different phase - and report occurred problems and how they supported or interfered with our teaching intentions.

In the agile community, there is a strong commitment to the few and simple principles and values that are collected in the agile manifesto. Those are a common guideline and a value system for agile methods. Rich process models suffer in having such principles and values. In this special panel, we aim at initiating a discussion on commonly agreed principles and values in rich process models, and at starting the work on a "Manifesto for Rich Process Models".

The V-Modell XT is the standard software development process for IT-projects in the German government. For federal agencies, this process is mandatory to manage internal IT-projects, as well as to coordinate projects of third-party suppliers. The non-profit organization "WEIT e.V." maintains the further development of the process model and provides official and industrial process owners with services. The process model is designed as a process line. Therefore the further development needs to be handled with care. In this position paper, we present the values that were chosen mandatory for the process's further development. We also motivate values that we consider relevant for rich process models in general.

A comprehensive software development process needs some adjustment before it can be used: It needs to be tailored to the particular organization's and project's setting. The definition of an appropriate tailoring model is a critical task. Process users need tailoring that enables them to trim the process to reflect the actual needs. Process engineers need a method and a tool to define a valid model. The SE Book of T-Systems contains a feature model to describe variable parts of the process model and relations and constraints between these parts. The notation and semantics of feature models can be used to visually author a consistent and valid tailoring model. In this paper we present a tool for visual modeling and validation of process model tailoring based on feature models using the SE Book of T-Systems as an example. The tool is based on a domain-specific language that represents the process model. It leverages the semantics of feature models to provide an easy-to-use editor for tailoring-enabled process models.

Global software engineering has become a fact in many companies due to real necessity in practice. In contrast to co-located projects global projects face a number of additional software engineering challenges. Among them quality management has become much more difficult and schedule and budget overruns can be observed more often. Compared to co-located projects global software engineering is even more challenging due to the need for integration of different cultures, different languages, and different time zones-across companies, and across countries. The diversity of development locations on several levels seriously endangers an effective and goal-oriented progress of projects. In this position paper we discuss reasons for global development, sketch settings for distribution and views of orchestration of dislocated companies in a global project that can be seen as a ldquovirtual project environmentrdquo. We also present a collection of questions, which we consider relevant for global software engineering. The questions motivate further discussion to derive a research agenda in global software engineering.

Today, distributed projects, often subsumed under terms like global software development (GSD), global collaboration, offshoring etc. are common ways to overcome time and budget restrictions or lack of personnel. Thus, today's projects take place in a global context. But developing software with geographically distributed teams presents a unique set of challenges that influence virtually all aspects of a project and make them more complex. This workshop addressed topics relevant in multi-site projects like tooling, process support, economic aspects, project management and collaboration and communication.