Home
Within the Software Engineering group we focus on three topics: knowledge management in relation to software architecture, service engineering, and the relation between social/organizational aspects of the development organization and technical aspects of the solution (known as “socio-technical congruence“). There are many links between those topics.
In a software architecture, the global structure of a system has been decided upon. This global structure captures the early, major design decisions, and the architectural design process is about making these design decisions. Architects and other stakeholders have to communicate and share knowledge about these design decisions. This brings us to the application of knowledge management to the field of software architecture. Our particular focus is the sharing of architectural knowledge (also in a global setting), and the discovery/retrieval of architectural knowledge from various artefacts.
Our research in the area of service engineering addresses the conceptual aspects of the development of service oriented architectures (SOA). This includes the identification of the key principles and challenges in the process-related aspects of the discipline (the service engineering methodologies) and the product-related aspects of conceptual modeling of SOAs (the requirements for design notations; the required architectural views and viewpoints; the service-specific architectural knowledge to be elicited, captured and transferred among service engineering professionals).
A new and challenging subfield within software engineering is to study the relation between the social structure of the team of developers, and the technical structure of the systems they develop (as phrased in Conway’s Law). Studying the actual social interaction between people involved may identify spots where the separation of concerns actually breaks. The underlying social structure can be further leveraged to indicate defect-vulnerable parts of the software, for example, a low level of communication within the team can lead to more defects injected in the code.