With the adoption of values, principles, practices, tools and processes from Agile, Lean, and DevOps, knowledge preservation has become a serious issue because documentation is largely left out.We identify two questions that are relevant for knowledge acquisition and distribution concerning design decisions, rationales, or reasons for code change.The first concerns which knowledge is required upfront to start a project.The second question concerns continuation after initial development and addresses which knowledge is required by those who deploy, use or maintain a software product.We evaluate two relevant approaches for alleviating the issues, which are 'Just enough Upfront' and 'Executable Documentation' with a total of 25 related artifacts.For the evaluation, we conducted a case study supported by a literature review, organizational and project metrics, and a survey.We looked into closed source-code and closed classified source-code.We found two conclusive remarks.First, git commit messages typically contain what has been changed but not why source-code has been changed.Design decisions, rationale, or reasons for code change should be saved as close as possible to the source-code with Git Pull Requests.Second, knowledge about a software product is not only written down in artifacts but is also a social construction between team members.

Group work skills are essential for Computer Scientists and especially Software Engineers. Group work is included in most CS curricula in order to support students in acquiring these skills. During group work, problems can occur related to a variety of factors, such as unstable group constellations or (missing) instructor support. Students need to find strategies for solving or preventing such problems. Student collaboration patterns offer a way of supporting students by providing problem-solving strategies that other students have already applied successfully. In this work we describe how student collaboration patterns were applied in an interdisciplinary software engineering project, and show that their application was generally experienced as helpful by the students.

A coherent description of enterprise architecture provides insight, enables communication among stakeholders and guides complicated change processes. Unfortunately, so far no enterprise architecture description language exists that fully enables integrated enterprise modeling, because for each architectural domain, architects use their own modeling techniques and concepts, tool support, visualization techniques, etc. In this paper, we outline such an integrated language and we identify and study concepts that relate architectural domains. In our language, concepts for describing the relationships between architecture descriptions at the business, application, and technology levels play a central role, related to the ubiquitous problem of business-ICT alignment, whereas for each architectural domain we conform to existing languages or standards such as UML. In particular, usage of services offered by one layer to another plays an important role in relating the behaviour aspects of the layers. The structural aspects of the layers are linked through the interface concept, and the information aspects through realization relations.

A coherent description of architectures provides insight, enables communication among different stakeholders and guides complicated (business and ICT) change processes. Unfortunately, so far no architecture description language exists that fully enables integrated enterprise modeling. In this paper we focus on the requirements and design of such a language. This language defines generic, organization-independent concepts that can be specialized or composed to obtain more specific concepts to be used within a particular organisation. It is not our intention to re-invent the wheel for each architectural domain: wherever possible we conform to existing languages or standards such as UML. We complement them with missing concepts, focusing on concepts to model the relationships among architectural domains. The concepts should also make it possible to define links between models in other languages. The relationship between architecture descriptions at the business layer and at the application layer (business-IT alignment) plays a central role.