Characterizing Changes to Assess Architectural Impact

With today’s ever increasing demands on software, software developers must produce software that can be changed without the risk of degrading the software architecture. Degraded software architecture is problematic because it makes the system more prone to defects and increases the cost of making future changes. The effects of making changes to software can be difficult to measure. One way to address software changes is to characterize their causes and effects. A software change characterization mechanism allows characterize the effects of a change using different criteria, e.g. the cause of the change, the type of change that needs to be made, and the part of the system where the change must take place. This information then can be used to illustrate the potential impact of the change. Another benefit of characterizing the changes is that it allows engineers to develop a common approach to deal with changes that have similar characteristics, rather than addressing each change individually. This paper introduces an architecture change characterization scheme created to assist developers in measuring the impact of a software change on the architecture of the system.

[1]  Proceedings of the 22nd international conference on Software engineering , 1976 .

[2]  E. Burton Swanson,et al.  The dimensions of maintenance , 1976, ICSE '76.

[3]  Victor R. Basili,et al.  Evaluation of a software requirements document by analysis of change data , 1981, ICSE '81.

[4]  Nazim H. Madhavji The Prism model of changes , 1991, [1991 Proceedings] 13th International Conference on Software Engineering.

[5]  Victor R. Basili,et al.  A classification procedure for the effective management of changes during the maintenance process , 1992, Proceedings Conference on Software Maintenance 1992.

[6]  David Chenho Kung,et al.  Change impact identification in object oriented software maintenance , 1994, Proceedings 1994 International Conference on Software Maintenance.

[7]  Mikael Lindvall,et al.  How well do experienced software developers predict software change? , 1998, J. Syst. Softw..

[8]  Jan Bosch,et al.  Architecture level prediction of software maintenance , 1999, Proceedings of the Third European Conference on Software Maintenance and Reengineering (Cat. No. PR00090).

[9]  Audris Mockus,et al.  Identifying reasons for software changes using historic databases , 2000, Proceedings 2000 International Conference on Software Maintenance.

[10]  Audris Mockus,et al.  Does Code Decay? Assessing the Evidence from Change Management Data , 2001, IEEE Trans. Software Eng..

[11]  François Lustman,et al.  A change impact model for changeability assessment in object-oriented software systems , 2002, Sci. Comput. Program..

[12]  David Garlan,et al.  Documenting software architectures: views and beyond , 2002, 25th International Conference on Software Engineering, 2003. Proceedings..

[13]  Reidar Conradi,et al.  An empirical study of software change: origin, acceptance rate, and functionality vs. quality attributes , 2004, Proceedings. 2004 International Symposium on Empirical Software Engineering, 2004. ISESE '04..

[14]  Susan P. Williams,et al.  Using card sorting technique to classify requirements change , 2004, Proceedings. 12th IEEE International Requirements Engineering Conference, 2004..

[15]  Martin Höst,et al.  The architectural change process , 2004, Proceedings. 2004 International Symposium on Empirical Software Engineering, 2004. ISESE '04..

[16]  Frank Tip,et al.  Chianti: a tool for change impact analysis of java programs , 2004, OOPSLA.

[17]  M M Lehman,et al.  Software Evolution , 2002 .