PDF Ebook Reconstructing Software Architecture Documentation for Maintainability
Software development is a complex and expensive undertaking. After the development of the software, the software enters the maintenance phase. Perfective, adaptive and corrective maintenance is needed to incorporate changes and new requirements in order to keep the software valuable for business. Unfortunately, the maintainability of software is frequently overlooked during the development of new systems in the software industry. The Content Management System (LBCMS) of Lost Boys is a typical example of this disposition. Enhancing the maintainability of a software system such as the LBCMS offers a significant payback opportunity, because maintenance costs can utilize up to 85% of the total cost of ownership of a software system. In addition, the correctness of changes and the quality of the design affect the quality of the software. If the maintainability of a system is poor, deterioration of the software will increase and the system rapidly looses its value for stakeholders.
There are no straightforward solutions for the maintenance problems at Lost Boys. This research proposes a solution for enhancing the maintainability by retrieving and documenting architectural knowledge of the LBCMS. The solution is based on the philosophy of software architecture and requirements engineering. However, most approaches for designing software architecture or capturing requirements assume that the system is yet to be build. Approaches for retrieving architectural information from established systems tend to focus on source code. Although source code contains architectural evidence, it is the result of certain design decisions and constraints. In this research, the approach for retrieving architectural knowledge for maintainability combines several approaches in order to understand the maintenance problems of Lost Boys from the perspective of stakeholders involved, to understand the architecture and capabilities of the system, and to effectively present the architectural knowledge in documentation in order to enhance the maintainability of the LBCMS.
The developed method to obtain the documentation consists of four phases; problem analysis, understanding requirements, understanding the architecture, and documenting the architecture. Thetechniques used in the approach are; interviews with stakeholders, stakeholder analysis, problem analysis, review workshops, source code browsing, and computer aided metrics.
The results of this research reside in the software architecture documentation of the LBCMS, in which the system is described from the perspective of business goals, stakeholder concerns, features, quality requirements, architectural views, and design decisions. A great effort is made to develop documentation in compliance with the information needs of stakeholders. In addition, the documentation has attributes which make the documentation itself maintainable, such as versioning, tracing, and verification. The correctness and completeness of the documentation is validated by means of interviews, system testing and a review workshop. The applicability of the documentation is validated by means of two personas, which represent two stakeholders at Lost Boys. In addition, an architectural strategy is developed as a guideline for Lost Boys for future improvement of the maintainability of the LBCMS. The approach and results are successful with respect to the goals of this research, and can be used in other projects to enhance a systems support for maintainability.
Contents
Abstract
Chapter 1 Introduction
- 1.1 Background & Context
1.2 Motivation for this Research
1.3 Research Goal
1.4 Research Questions
1.5 Structure of this Thesis
Chapter 2 Software Maintainability and the Role of Documentation
- 2.1 Introduction
2.2 The Evolution of Software
2.3 Software Quality
2.4 Software Maintenance
2.5 Software Documentation
2.6 Conclusion
Chapter 3 Problem Analysis
- 3.1 Introduction
3.2 The problem description according to Lost Boys
3.3 The causes & effects
3.4 Why is this a problem
3.5 The problem from the perspective of John Foo; a Software Engineer
3.6 The problem from the perspective of Miranda Bar; a Technical Consultant
3.7 The impact of the problem
3.8 Possible solutions
3.9 Hypothesis
Chapter 4 Approach for retrieving architectural knowledge
- 4.1 Existing methods for retrieving architectural knowledge
4.2 Approach
4.3 Understanding the Requirements of the LBCMS
4.4 Understanding the Software Architecture of the LBCMS
4.5 Validation of the results
Chapter 5 Understanding Requirements: Software Requirements Specification
- 5.1 Approach to Requirements Engineering
5.2 Stakeholders and their Concerns
5.3 Business Goals
5.4 Feature Requirements
5.5 Quality Requirements
5.6 Conclusion
Chapter 6 Understanding Architecture: Software Architecture Documentation
- 6.1 Approach
6.2 Understanding the internal structure
6.3 Design Decisions
6.4 Architectural Views
6.5 Maintainability Tactics
6.6 Conclusion
Chapter 7 Results and Conclusion
- 7.1 Validation of the documentation
7.2 Assessment of the Applicability of the Documentation
7.3 How the documentation supports the tasks of John Foo and Miranda Bar
7.4 Discussion
7.5 Conclusion
References
Appendix A Software Requirements and Architecture Documentation
Appendix B Workshop presentation
Download
PDF Ebook Reconstructing Software Architecture Documentation for Maintainability
Posted in :
