Architectural knowledge consists of architecture design as well as the design decisions, assumptions, context, and other factors that together determine why a particular solution is the way it is. Except for the architecture design part, most of the architectural knowledge usually remains hidden, tacit in the heads of the architects. We conjecture that an explicit representation of architectural knowledge is helpful for building and evolving quality systems. If we had a repository of architectural knowledge for a system, what would it ideally contain, how would we build it, and exploit it in practice? In this paper we describe a use-case model for an architectural knowledge base, together with its underlying ontology. We present a small case study in which we model available architectural knowledge in a commercial tool, the Aduna Cluster Map Viewer, which is aimed at ontologybased visualization. Putting together ontologies, use cases and tool support, we are able to reason about which types of architecting tasks can be supported, and how this can be done.

Social debt is analogous to technical debt in many ways: it represents the state of software development organisations as the result of "accumulated" decisions. In the case of social debt, decisions are about people and their interactions. Our objective was to study the causality around social debt in practice. In so doing, we conducted exploratory qualitative research in a large software company. We found many forces together causing social debt; we represented them in a framework, and captured anti-patterns that led to the debt in the first place. Finally, we elicited best practices that technicians adopted to pay back some of the accumulated debt. We learned that social debt is strongly correlated with technical debt and both forces should be reckoned with together during the software process.

No abstract

No abstract

Software engineering evolved from a rigid process to a dynamic interplay of people (e.g., stakeholders or developers). Organizational and social literature call this interplay an Organizational Social Structure (OSS). Software practitioners still lack a systematic way to select, analyze, and support OSSs best fitting their problems (e.g., software development). We provide the state-of-the-art in OSSs, and discuss mechanisms to support OSS-related decisions in software engineering (e.g., choosing the OSS best fitting development scenarios). Our data supports two conclusions. First, software engineering focused on building software using project teams alone, yet these are one of thirteen OSS flavors from literature. Second, an emerging OSS should be further explored for software development: social networks. This article represents a first glimpse at OSS-aware software engineering, that is, to engineer software using OSSs best fit for the problem.