Effort Estimation in Capturing Architectural Knowledge

Abstract

Abstract

The Decision View's Role in Software Architecture Practice

“…(i) the perceived value of designs decisions and design rationale for different kinds of stakeholders, as different items for representing and recording the information of design decisions may not have the same importance for all stakeholders [17]. Hence, we should decide which type of knowledge would better fit each type of users, (ii) the effort in capturing decisions during the early development stages pays off in later maintenance and evolution phases, thus expecting return of the investment when decisions are captured for the first time [18]. The experiences described there also highlight the benefits of using specific tool support for capturing, managing, and documenting architectural design decisions.…”

“…Therefore, the overhead required during the creation of these decisions should pay off during maintenance, as key design decisions avoid the need to reverse architecture descriptions from code, particularly in staff turnover situations, or rapid software evolution. Long-term benefits and a reduction of maintenance costs (e.g., architecture recovery) are expected to motivate users to capture the design rationale, in particular in successive iterations of the system evolution [18]. Hence, the broad impact for capturing and using architecturally significant design decisions affects not only the evolution of designs but also the evolution and maintenance of the decisions base itself.…”

10 years of software architecture knowledge management: Practice and future

“…The customizable features of ADDM, such as a personalized AK reuse facility or customized storage, increases user satisfaction and provides a more flexible tool. Some extensions to the tools have made, such as for instance basic customization and reuse mechanisms incorporated into ADDSS version 2.0 ( Capilla et al, 2008 ) as well as timers in version 2.1 to measure the capturing effort of the decisions and RSS feeds to keep users aware of the changes in the decisions and tailor AK to different stakeholders .…”

“…Effort in capturing AK : Managers and designers do not often perceive valuable spent effort and resources capturing the relevant design decisions, producing additional documentation and maintaining the decisions captured with the links to other software artifacts. The efforts or costs necessary for capturing the decisions and AK are immediately realized and they occur during the different phase of the software development lifecycle ( Capilla et al, 2008 ). However, the benefits of capturing AK are not something that is immediately recognized and easily justifiable.…”

Evolution styles: using architectural knowledge as an evolution driver

“…For instance, Burge, Carroll, and McCall stated in that as the rationale describes the history of how and why the system has been modified over time, it ‘should be captured for the change’ to determine where problems have usually happened and where they are likely to emerge. Other approaches have also highlighted that the necessary work to specify AK really pays off when the system is in its maintenance and evolution phases by helping to reduce the costs of these phases.…”