IN THIS CHAPTER, YOU WILL LEARN:

For many systems analysts, the project is over when the structured specification has been finished and accepted by the user. At this point, the specification is delivered to an implementation team of designers and programmers who will build a system from the specification.

Of course, some systems analysts remain with the project through the design and implementation phases. Sometimes the systems analyst serves as a project manager, guiding and directing the efforts of the implementation team. Sometimes the systems analyst remains with the project to continue doing systems analysis, that is, to continue serving as an intermediary between the user and the implementation team. And the systems analyst may also be involved in the development of user manuals, acceptance test data, installation planning, and a variety of other complementary activities that can take place concurrently with the implementation process.

However, almost all systems analysts leave the project after development has been completed and the new system is put into operation. Some programmers will remain to carry out maintenance activities, but when the development phase finishes, the party is over, and most of the systems analysts, designers, and programmers will move on to new projects (and often new companies, where they can get a larger salary than their current employer will pay!).

But the work done by the systems analyst (all the work discussed throughout this book) continues to be important. Just as the computer programs must be maintained during the 5, 10, or 20 years of the operational life of the system, so the specification must be maintained as well. Or, to put it another way, various aspects of the implementation of the system will be changed during the system’s lifetime, and for each of those changes an appropriate, corresponding change must be made to the specification.

Though the original systems analyst may not remain with the project during its operational lifetime, it is important for him or her to leave behind a legacy that can be maintained. This chapter discusses the maintenance of the system specification.

24.1 WHY IT’S IMPORTANT

At this point, you may be rather puzzled; after all, you may be thinking, it’s perfectly obvious that the system specification be kept up to date. Why would anyone do things differently? Unfortunately, the history of the systems development field suggests otherwise: the vast majority, probably more than 80%, of systems currently in operation do not have an accurate, up-to-date statement of the user requirements that the system is carrying out.

This is not a phenomenon unique to the computer field. How many century-old houses have up-to-date documents describing the wiring, plumbing, heating, and other architectural details? The simple truth is that it’s often a lot easier to make a “quick-and-dirty” correction, improvement, or change to an existing system than it is to begin by changing the requirements document and then propagating that change through the design document and the implementation itself. This is especially true if the change needs to be made to fix an immediate, pressing, urgent problem [1]. “We’ll get around to changing the documentation later,” the maintenance person will say, “but first we have to fix the problem itself.” Documentation is the last thing that anyone wants to do, and often it never gets done at all.

Information systems have an important characteristic when it comes to maintenance: they last longer than the developers or the users who were involved in the original development of the system. This is true of houses, too; neither the architect nor the end user of a Victorian townhouse built in the 1880s is available for consultation today. And it is true of many information systems, too; after 10 or 20 years, the system is being used by third-generation users (some of whom may have no idea why the system was developed in the first place) and is being maintained by third-generation maintenance programmers (some of whom may have no idea why the original developers adopted a particular design strategy). [2] This is why Nicholas Zvegintzov describes maintenance programmers as the “reverse engineers of society.”

There is something else important about information systems: they tend to be complex from the outset, and they grow increasingly complex as they undergo years of maintenance. If a system were simple (e.g., 250 Visual Basic statements), then it could be maintained easily even if it had no documentation. But a typical system has at least 100,000 program statements; many of the larger systems presently being maintained have well over 500,000 statements; and some have over one million statements. No one person can understand the complexity of such a system, especially if (1) he or she was not involved in the development of the original system, and (2) the requirements and design of the original system were not documented. And yet that is exactly what we ask most of our maintenance programmers to do. [3]

There are dozens, if not hundreds, of examples of organizations with severe maintenance problems of the sort described above. Virtually every major organization that began computerizing 20 years ago is now faced with 20-year-old systems whose implementation is a mystery and, far worse, whose user requirements are a mystery.

The only solution to this crisis in the future is to maintain accurate, up-to-date documentation for as long as the system itself survives. But how do we do this?

24.2 NECESSARY PREREQUISITES

We can’t keep a system and its associated documentation up to date if the documentation isn’t accurate to begin with. So this is the starting point: we must ensure that when a new system is put into operation, all the related documents are complete, consistent, accurate, and up-to-date.

Throughout this book, we have discussed the characteristics of an accurate model of user requirements, as well as guidelines for ensuring that the system model is complete and internally consistent. In order for ongoing maintenance to be successful, these guidelines must be enforced, and an independent person or group must certify that the documentation is accurate before the system is put into operation.

In addition to certifying that the documents themselves are accurate, we must ensure that there is a mechanism for making ongoing changes to the documents. It will do us no good if the structured specification has been permanently enscribed with a stainless steel stylus on stone tablets as a permanent record for future generations; the specification must be seen as a living document, subject to constant, though controlled, change.

24.3 HOW TO DO IT

The first and most fundamental rule of systems maintenance is this: any proposed change to the existing operational system must, in all cases, begin with an examination of the impact on the system’s specification of requirements. This must be done in all of the cases illustrated next, together with any other proposed system change:

Any such change must be illustrated, documented, and verified with the user by making the appropriate changes on the system model. This is usually done by filling out a form known as a system change request. The maintenance change may involve any or all of the following:

Any such change will not be free. It is possible that some changes will be minimal and will require only a few minutes of work to incorporate — only a few minutes to make the necessary changes to the specification and the existing computer programs. However, the person or group making the change has an obligation to go through the exercise of writing an impact statement: a precise and detailed statement of the changes that will need to be made to the system specification in order to implement the proposed change. Along with this, there should be an economic impact statement: a statement of the cost of making the change and the estimated benefit to be derived from the change. This is particularly important if the maintenance activity will change the scope of the system.

Of course, there will be some changes that have no impact on the system specification: a programming correction to fix a bug, a coding change to enhance the readability or efficiency of the existing system, or a change of the existing computer hardware or systems software (compiler, operating system, database management system, etc.). However, even in these cases, an economic impact statement should be generated so that the user and the systems development organization will understand the costs and benefits associated with the change.

Any change in the system will typically result in a change to the software and/or the hardware of the system; it may also result in a change to the user manuals, operating procedures, and various other components of the system. But by far the most important document to keep up to date is the statement of user requirements! Without it, future changes and modifications will become more and more difficult to make; and the change to an altogether new system will be infinitely more expensive, time consuming, and painful than it should be.

No doubt this plea for an up-to-date system specification would be viewed with a jaundiced eye by a veteran systems analyst with 20 years experience. After all, the process of systems analysis has been so difficult for so many years, and the task of developing an accurate system specification has been so difficult, that the notion of keeping it permanently up to date seems almost ludicrous.

The answer, in the long run, will be automation. Automated systems analysis workstations of the sort described in Appendix A are now available at affordable costs, and they represent a dramatic improvement over the technology used by most systems analysts today, just as word processing systems represent a dramatic improvement over the electric typewriter of the 1960s. More ambitious plans are underway to develop all-encompassing, integrated software engineering environments that will serve as a central repository for all the documents associated with the development of a system. However, the backlash from early experiments with automated tools, together with the intense pressure to develop new systems more and more quickly, has slowed the deployment and adoption of this technology throughout the industry; it could well be another decade before it is accepted as standard practice.

However, there is much to be done even with the technology available today. There is simply no excuse for making a change to an existing system without making the corresponding change to the system specification. To make this work, though, requires strong, disciplined management within the IT organization.

24.4 SUMMARY

There is a growing body of literature on the subject of software maintenance, as well as at least one professional society (the Software Maintenance Association) concerned with issues of maintenance. However, most current emphasis is on the management and refurbishing of existing programs; there is also some emphasis on the use of good design techniques to create maintainable programs. But the systems development industry is only now beginning to realize that without maintainable specifications we will never have maintainable software.

REFERENCES

FOOTNOTES