Marco Kuhrmann

Criteria for software process tailoring: a systematic review

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.

Das V-Modell XT

Als die Bundesrepublik Deutschland Mitte der 80er Jahre damit begann, das V-Modell zu entwickeln, stand vor allem eins im Vordergrund: Inhalt. Es sollte klar festgelegt werden, wie der Softwareentwicklungsprozess der Auftragnehmer des Bundes aussieht. Die Inhalte fanden internationale Beachtung. Sie waren allerdings in Form einfacher Textdokumente festgeschrieben. Dies gilt fur das V-Modell 92 und das V-Modell 97.

Hybrid software and system development in practice: waterfall, scrum, and beyond

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.

Software process improvement: a systematic mapping study on the state of the art

Software process improvement (SPI) has been around for decades: frameworks are proposed, success factors are studied, and experiences have been reported.However, the sheermass of concepts, approaches, and standards published over the years overwhelms practitioners as well as researchers. What is out there? Are there new trends and emerging approaches?What are open issues? Still, we struggle to answer these questions about the current state of SPI and related research. In this article, we present results from an updated systematic mapping study to shed light on the field of SPI, to develop a big picture of the state of the art, and to draw conclusions for future research directions. An analysis of 769 publications draws a big picture of SPI-related research of the past quarter-century. Our study shows a high number of solution proposals, experience reports, and secondary studies, but only few theories and models on SPI in general. In particular, standard SPImodels likeCMMI and ISO/IEC 15,504 are analyzed, enhanced, and evaluated for applicability in practice, but these standards are also critically discussed, e.g., from the perspective of SPI in small-to-medium-sized companies, which leads to new specialized frameworks. New and specialized frameworks account for the majority of the contributions found (approx. 38%). Furthermore, we find a growing interest in success factors (approx. 16%) to aid companies in conducting SPI and in adapting agile principles and practices for SPI (approx. 10%). Beyond these specific topics, the study results also show an increasing interest into secondary studies with the purpose of aggregating and structuring SPI-related knowledge. Finally, the present study helps directing future research by identifying under-researched topics awaiting further investigation. Subjects Software Engineering

Systematic software process development: where do we stand today?

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.

GloSE-Lab: Teaching Global Software Engineering

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.

Orchestration of Global Software Engineering Projects - Position Paper

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 “virtual project environment”. 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.

On the pragmatic design of literature studies in software engineering: An experience-based guideline

Systematic literature studies have received much attention in empirical software engineering in recent years. They have become a powerful tool to collect and structure reported knowledge in a systematic and reproducible way. We distinguish systematic literature reviews to systematically analyze reported evidence in depth, and systematic mapping studies to structure a field of interest in a broader, usually quantified manner. Due to the rapidly increasing body of knowledge in software engineering, researchers who want to capture the published work in a domain often face an extensive amount of publications, which need to be screened, rated for relevance, classified, and eventually analyzed. Although there are several guidelines to conduct literature studies, they do not yet help researchers coping with the specific difficulties encountered in the practical application of these guidelines. In this article, we present an experience-based guideline to aid researchers in designing systematic literature studies with special emphasis on the data collection and selection procedures. Our guideline aims at providing a blueprint for a practical and pragmatic path through the plethora of currently available practices and deliverables capturing the dependencies among the single steps. The guideline emerges from various mapping studies and literature reviews conducted by the authors and provides recommendations for the general study design, data collection, and study selection procedures. Finally, we share our experiences and lessons learned in applying the different practices of the proposed guideline.

A mapping study on the feasibility of method engineering

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

Towards Artifact Models as Process Interfaces in Distributed Software Projects

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.