Software Architecture Knowledge Management

Software architecture is a recognized and indispensable part of system development. Software architecture is often defined in terms of components and connectors, or the "high-level conception of a system". In recent years, there has been an awareness that not only the design itself is important to capture, but also the knowledge that has led to this design. This so-called architectural knowledge concerns the set of design decisions and their rationale. Capturing architectural knowledge is difficult. Part of it is tacit and difficult to verbalize. Like developers, software architects are not inclined to document their solutions. Establishing ways to effectively manage and organize architectural knowledge is one of the key challenges of the field of software architecture. This architectural knowledge plays a role during development, when architects, developers, and other stakeholders must communicate about the system to be developed, possibly in a global setting. It also plays a role during the evolution of a system, when changes are constrained by decisions made earlier.

[1]  Patricia Lago,et al.  The Architect's Mindset , 2007, QoSA.

[2]  Patricia Lago,et al.  Global Software Development: Are Architectural Rules the Answer? , 2007, International Conference on Global Software Engineering (ICGSE 2007).

[3]  Kevin C. Desouza,et al.  Managing Knowledge in Global Software Development Efforts: Issues and Practices , 2006, IEEE Software.

[4]  Dieter K. Hammer,et al.  Tool Support for Architectural Decisions , 2007, 2007 Working IEEE/IFIP Conference on Software Architecture (WICSA'07).

[5]  Patricia Lago,et al.  Architectural Knowledge: Getting to the Core , 2007, QoSA.

[6]  David A. Patterson.  Revisiting my campaign statement , 2006, CACM.

[7]  Frank Maurer,et al.  Social Factors Relevant to Capturing Design Decisions , 2007, Second Workshop on Sharing and Reusing Architectural Knowledge - Architecture, Rationale, and Design Intent (SHARK/ADI'07: ICSE Workshops 2007).

[8]  Patricia Lago,et al.  Assessing a Multi-Site Development Organization for Architectural Compliance , 2007, 2007 Working IEEE/IFIP Conference on Software Architecture (WICSA'07).

[9]  Philippe Kruchten,et al.  Building Up and Reasoning About Architectural Knowledge , 2006, QoSA.

[10]  Muhammad Ali Babar,et al.  Architectural Knowlege Management Strategies: Approaches in Research and Industry , 2007, Second Workshop on Sharing and Reusing Architectural Knowledge - Architecture, Rationale, and Design Intent (SHARK/ADI'07: ICSE Workshops 2007).

[11]  M. E. Conway.  HOW DO COMMITTEES INVENT , 1967 .

[12]  D. L. Parnas,et al.  On the criteria to be used in decomposing systems into modules , 1972, Software Pioneers.

[13]  Hans de Bruin,et al.  Documenting and Analyzing a Context-Sensitive Design Space , 2002, WICSA.

[14]  Patricia Lago,et al.  Eagle: Effective Tool Support for Sharing Architectural Knowledge , 2007, Int. J. Cooperative Inf. Syst..

[15]  Axel van Lamsweerde,et al.  Goal-Oriented Requirements Engineering: A Guided Tour , 2001, RE.

[16]  Philippe Kruchten,et al.  The Rational Unified Process: An Introduction , 1998 .

[17]  Axel van Lamsweerde,et al.  Goal-oriented requirements enginering: a roundtrip from research to practice [enginering read engineering] , 2004, Proceedings. 12th IEEE International Requirements Engineering Conference, 2004..

[18]  Jan Bosch,et al.  Software Architecture: The Next Step , 2004, EWSA.

[19]  Jeff Tyree,et al.  Architecture decisions: demystifying architecture , 2005, IEEE Software.

[20]  Remco C. de Boer,et al.  Constructing a Reading Guide for Software Product Audits , 2007, 2007 Working IEEE/IFIP Conference on Software Architecture (WICSA'07).

[21]  Martin Fowler.  Design - Who needs an architect? , 2003, IEEE Software.

[22]  Dewayne E. Perry,et al.  People, organizations, and process improvement , 1994, IEEE Software.