Software Maintenance Maturity Model
Sandesh Tattitali
Software Maintenance Management: Evaluation and Continuous Improvement, by Alain April and Alain Abran, Wiley-IEEE Computer Society Press, ISBN-10: 0470147075, ISBN-13: 978-0470147078, 314 pp.
This book addresses an important yet overlooked phase of the software development life cycle—namely, maintenance. In my 15 years’ experience, I’ve found time and again that software organizations treat maintenance activities the same as new development activities. This can lead to weird scenarios, where you just know that something isn’t seem right. Software Maintenance Management makes a clear distinction between the two activities and proposes a new maturity model—along the lines of the CMMI—for software maintenance.
Professors April and Abran start off with the main issue, which is that most organizations have no defined processes for their software maintenance activities. The authors survey research from the past 30 years and empirical data that show the maintenance benefits of improved processes viz. productivity, costs, quality, customer satisfaction, and ROI. They cite the SWEBOK (Software Engineering Body of Knowledge), which recognizes the importance of software maintenance but offers no defined process model for it. The authors then define the Software Maintenance Maturity Model (S3m). They base the model on their literature search and the results of extensive interviews with maintenance managers and specialists.
The book is divided into three overall parts. Part I covers issues associated with current views of maintenance issues. I found this part of the book most interesting and engaging. The authors show the maintenance phase accounting for 50 to 90 percent of total software costs. Customers see the issues centering on high costs, slow delivery, and misplaced priorities, whereas software programmers see the issues relating to poor software design, development, and documentation. Unlike hardware, software isn’t usually modular in a way that easily confines the side effects associated with change. Furthermore, you can’t replace components in the same way, and we don’t have tests and diagnostics at the touch of a button. Finally, many maintenance requests are for enhancements, rather than fixes, so software evolution is an additional complicating maintenance issue.
Part II covers the S3m model. The authors modeled it after the CMMI, and they explain why—specifically, CMMI itself doesn’t address software maintenance. They make the case that the CMMI addresses project management during development, whereas the S3m addresses queue/event management, which is more appropriate during the software maintenance phase. They also distinguish between engineering and evolution engineering, dividing their model into four distinct domains:
- software maintenance process management,
- software maintenance request management,
- software evolution engineering, and
- support to software evolution.
Each domain includes defined key process areas (KPAs). For example, maintenance focus KPA, maintenance planning KPA, and so on. Each KPA is described in terms of the objectives, goals, expected results, and links to other KPAs.
Part III details exemplary practices in the four process domains and details the various maturity levels that a company can achieve as it moves up the maturity model ladder. Each level involves an information-gathering roadmap, arriving at the findings, and then creating an action plan. This is by far the driest part of the book. The authors conclude with four cases where S3m was used to improve the maintenance activities at four different organizations. To be successful requires defining software maintenance itself and any agreements, including SLAs (service level agreements); supporting the products with quality measures; and ensuring that intermediate products are produced in the form of documentation.
A concluding summary does a great job in highlighting the book’s key features. Appendix B contains term assignments for students. Appendix C is the glossary—one of the most extensive I’ve seen in any software book.
I had mixed feelings about the book. Although the authors intend this to be a textbook for students, the issues it raises could resonate more with seasoned professionals in the field. Plus in this age of agile methodologies and “the less process, the better,” it seems unlikely that a new maturity model will be looked upon kindly, especially one modeled after CMMI.
However, the issues raised in Software Maintenance Management were all too familiar. While I would have liked a lot more concrete advice on how to go about creating a maintenance organization, just bringing the issues forward and analyzing them in depth was helpful. To me, that’s the book’s greatest contribution to the existing body of software knowledge. Managers and even seasoned professionals would be doing themselves a disservice by not at least browsing the book for that information.
Sandesh Tattitali is a system architect at Flagstar Bank. Contact him at stattit@gmail.com.
