Industrial Perspective on the Usefulness of Design Rationale for Software Maintenance: A Survey

Software maintenance is widely known as a problematic area that may consume up to 80% of a software project's resources. It has been claimed that providing an effective mechanism to access design rationale (DR) has great potential to improve software maintenance processes. However, we postulate that the first step towards exploring the potential of DR for improving software maintenance should be to gain a better understanding of what DR means to practitioners, how valuable they consider DR to be and how they use DR. To determine the perceived usefulness of DR, we surveyed a large number of software designers. This exploratory study has discovered that practitioners recognize the importance of DR to understand existing designs and frequently use it to reason about proposed modifications. The results of this study establish that DR is perceived by practitioners to be useful and the efforts required to capture DR for the purpose of maintenance are worthwhile. The findings allow us to identify areas of further research on DR support that have the potential to improve the maintenance process

[1]  Muhammad Ali Babar,et al.  A Survey of the Use and Documentation of Architecture Design Rationale , 2005, 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05).

[2]  Bill Curtis,et al.  A field study of the software design process for large systems , 1988, CACM.

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

[4]  Maria Joao C. Sousa,et al.  A survey on the Software Maintenance Process , 1998, Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272).

[5]  Jun Han.  Designing for increased software maintainability , 1997, 1997 Proceedings International Conference on Software Maintenance.

[6]  Izak Benbasat,et al.  Development of an Instrument to Measure the Perceptions of Adopting an Information Technology Innovation , 1991, Inf. Syst. Res..

[7]  Mira Kajko-Mattsson,et al.  A Survey of Documentation Practice within Corrective Maintenance , 2004, Empirical Software Engineering.

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

[9]  Carolyn B. Seaman,et al.  The information gathering strategies of software maintainers , 2002, International Conference on Software Maintenance, 2002. Proceedings..

[10]  Muhammad Ali Babar,et al.  A survey of architecture design rationale , 2006, J. Syst. Softw..

[11]  Simon J. Shum.  A cognitive analysis of design rationale representation , 1991 .

[12]  Thomas R. Gruber,et al.  Design Knowledge and Design Rationale: A Framework for Representation, Capture, and Use , 1991 .

[13]  Vasant Dhar,et al.  Supporting Systems Development by Capturing Deliberations During Requirements Engineering , 1992, IEEE Trans. Software Eng..

[14]  Fred D. Davis.  Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology , 1989, MIS Q..

[15]  Björn Regnell,et al.  Is a Design Rationale Vital when Predicting Change Impact? A Controlled Experiment on Software Architecture Evolution , 2000, PROFES.

[16]  Olly Gotel,et al.  An analysis of the requirements traceability problem , 1994, Proceedings of IEEE International Conference on Requirements Engineering.

[17]  Fred P. Brooks,et al.  The Mythical Man-Month , 1975, Reliable Software.

[18]  Laurent Karsenty,et al.  An empirical evaluation of design rationale documents , 1996, CHI.

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

[20]  Jintae Lee,et al.  Design Rationale Systems: Understanding the Issues , 1997, IEEE Expert.

[21]  Paul J. Layzell,et al.  Expert maintainers' strategies and needs when understanding software: a case study approach , 2001, Proceedings Eighth Asia-Pacific Software Engineering Conference.

[22]  Masaki Hamada,et al.  Recording software design processes for maintaining the software , 1993, Proceedings of 1993 IEEE 17th International Computer Software and Applications Conference COMPSAC '93.

[23]  E. Burton Swanson,et al.  Characteristics of application software maintenance , 1978, CACM.

[24]  IEEE-SA Standards Board , 2000 .

[25]  Antony Tang,et al.  Architecture rationalization: a methodology for architecture verifiability, traceability and completeness , 2005, 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS'05).

[26]  Cornelia Boldyreff,et al.  Using application understanding to support impact analysis , 1998, J. Softw. Maintenance Res. Pract..

[27]  Colin Potts,et al.  Recording the reasons for design decisions , 1988, Proceedings. [1989] 11th International Conference on Software Engineering.

[28]  Loren G. Terveen,et al.  Managing design knowledge to provide assistance to large-scale software development , 1992, Proceedings of the Seventh Knowledge-Based Software Engineering Conference.

[29]  Charles L. A. Clarke,et al.  Archetypal source code searches: a survey of software developers and maintainers , 1998, Proceedings. 6th International Workshop on Program Comprehension. IWPC'98 (Cat. No.98TB100242).

[30]  David Lorge Parnas,et al.  A rational design process: How and why to fake it , 1986, IEEE Transactions on Software Engineering.

[31]  Thomas M. Pigoski.  Practical Software Maintenance: Best Practices for Managing Your Software Investment , 1996 .

[32]  I. Ajzen.  The theory of planned behavior , 1991 .

[33]  James D. Herbsleb,et al.  Preserving knowledge in design projects: what designers need to know , 1993, INTERCHI.

[34]  Alexander L. Wolf,et al.  Acm Sigsoft Software Engineering Notes Vol 17 No 4 Foundations for the Study of Software Architecture , 2022 .

[35]  David C. Brown,et al.  Rationale Support for Maintenance of Large Scale Systems , 2003 .

[36]  P. Kidwell,et al.  The mythical man-month: Essays on software engineering , 1996, IEEE Annals of the History of Computing.