Software maintenance is often overlooked in the design and development process when, due the funds and resources it takes, it should be considered equally as important as design and development. Maintenance is often also taken to mean the alteration of code (or other system parts) to remove bugs inherited from the software design and development phases, however surveys have found that this represents only 20% of ‘maintenance’ activity (Pigosky, T. (1996)).
In addition, Zaghal, Ahues & Voehl (2002) demonstrated that, in a games software development scenario, a maintenance orientated software design and development process vastly reduced the time required to maintain the software which. They postulate that by developing automated coding and validation routines designed specifically for maintenance routines in the design and development stage, if it was possible to apply this technique to other developments, this would pay great dividends in terms of time and funds.
Improving the ability to maintain software by efforts at the design and development stage is dictated a great deal by the perspective of those involved. In order for such perspectives to be taken into account the designer / developer (not necessarily a single person or entity) needs to consider many more maintenance factors than usually related with software development; the main ones being technical, human, financial and legal.
The traditional design and development methodology in the software lifecycle revolves around the writing of a requirements specification, designing how the requirements will be met and implementing the development and, from my own experience, it is those developments where time is spent on requirements gathering and documentation, especially with stakeholders who often need a designer at the top of their game in order to extract the required information, where more dividends are paid in maintenance as the software becomes more suitable for purpose and easier to develop functionally, a major part of maintenance that it not, actually, a maintenance function.
Many software development projects, in my experience, are too focussed on the first goal of producing something that works in order to obtain user acceptance and the stakeholder is often unaware, due to their lack of systems knowledge, of the difficulties that will be involved in ‘maintaining’ the system after they have signed off user acceptance documents. As with object-orientated development, the resulting dividends are often helped a great deal by an experienced and, dare I say it, ethical development team in the real world.
Association for Computing Machinery (1999): Software Engineering Code of Ethics and Professional Practice [Online]. Available at: http://www.acm.org/about/se-code#full (Accessed 12 December 2009).
Glenn, J. (2009) Computer Science: An Overview. 10th ed. Boston: Pearson Education.
Pigosky, T. (1996) Practical Software Maintenance: Best Practices for Managing Your Software Environment New York: Wiley.
Wikipedia: Software Maintenance [Online]. Available at: http://en.wikipedia.org/wiki/Software_maintenance (Accessed 12 December 2009).
Zaghal, Ahues & Voehl (2002): Maintenance-Oriented Design and Development: A Case Study [Online]. Available at: http://alarcos.inf-cr.uclm.es/doc/MetoTecInfInf/Articulos/8-zagal et al case study.pdf (Accessed 12 December 2009).