Planned approach to systems support by DOREEN WHEELER

M aintaining and supporting ex- isting systemswill never be the most glamorous aspect of data

processing. In fact, most members of

the DP department consider an as- signment to support work as some- thing to be avoided at all costs. It is, nevertheless, an essential task which needs to be done well if systems are

not to become liable to failure when they are needed most.

Statistics indicate that 60-70% of an average DP department’s time is spent on the vital activity of support- ing existing software. When over- heads are taken into account, usually at least doubling direct labour costs, as well as unquantifiable costs, such as high staff turnover, recruitment and

training, the financial merits of sub- contracting support work may look attractive. There are, in addition, nonfinancial considerations, concern- ing quality of service, that may be deciding factors. A large third party service organization can, for instance,

usually afford to have fully trained backup staff to cover for holidays and

sickness whereas system users them- selves may not be able to justify this.

Organizations aiming to take on the support, not only of systems they have built themselves, but also those written by other people, have a daunt- ing task - but one which can be rewarding if approached in an organ- ized and disciplined way. The key to

turning support work into a success- ful business and, at the same time making a valuable contribution to the careers of those involved, is a planned

approach to quality, cost control and

staffing. There is no magic formula for turning other people’s coding into a source of interest eyuafling the creation of new systems; support operations can, however, be tackled in a way that benefits both system users and staff who undertake the work.

System audit

Before embarking on a support pro- gramme, it is wise to make a thorough audit of the system, assessing how much work will initially be needed to bring it up to a standard at which a routine maintenance scheme can sens- ibly begin. Only when a sound start-

ing point has been established can the support team begin its work with any confidence of achieving results it can be proud of.

Documentation is a prime area in

which neglect of the support function will show itself and a careful evalua- tion here will normally be the first stage in any audit. If extra documen- tation is required, then the necessary material, which may include function- al specifications, user manuals or operating instructions, should be completed as a foundation for all further work on the system. One has

to be realistic about documentation and accept that program specifications are now always kept up to date. This,

however, forces programmers to dive straight into the code where they can

waste a great deal of time with no result. To avoid such waste of time and money in the future proper docu- mentation is essential.

~0126 no 1 januaryifebruary 1984 001 I-684X:84/01001 l-02$03.00 @ 1984 Butterworth & Co (Publishers) Ltd 11

Modifications

Having brought documentation up to scratch, the next logical step is to prepare a plan based upon known modification requirements and allow- ing for anticipated operational sup- port. If an independent quality con- trol department has been established within the support organization, then it should be given the opportunity to review plans before they are submit- ted to system users. In the long term, a successful support operation will depend on consistent, well documen- ted, well planned work with standard procedures set up to control initiation and implementation of changes. A change control file, containing records of each change and enhancement, can form a useful central reference point for details about actions taken and who took them. If possible, each line of code amended should have a com- ment together with a modification reference number and initials of the person who made the change. Thus, making things easier, not more diffi- cult, for their successors.

Ensuring that a modification actual- ly works under all circumstances is obviously essential if problems are not to be stored up for the future. As much importance should be placed on the testing as on the implementation. When a system fails after a modifica- tion has been made, how many times have we all heard ‘But I only changed X’, where X is some minor factor not judged sufficient to warrant proper testing but, nevertheless, quite enough to cause a failure. At the time of designing the modification an ade- quate test plan should also be devised, encompassing associated programs.

It is easy and tempting to skimp the test phase but if test files, which are short with well designed contents rather than large live data files, are available, this will relieve the tedium and shorten the process. In very complex systems, it may well be worth considering a parameter-driven model to simulate volume tests. When they do not already exist, setting up

test beds can be costly, but if the system is to be modified and enjoy a reasonable life span, then this is money well spent. Ultimately, the user should always satisfy him/her- self, with his/her own acceptance tests, that all is well. Signing of the acceptance document by the user will form part of the change control file, along with the other details. Last but not least, user and operational in- structions must be amended as neces- sary.

Error correction

Procedures for error correction can be much the same except that when a ‘cannot wait’ priority is assigned to the problem, paperwork will have to be completed after a solution is found. In less urgent situations, assigning a ‘correct by next run’ priority leaves more time for the necessary planning and preparation.

As anyone involved in trouble- shooting will know, the user is not always the best ally in error correcting exercises; ‘the system crashed’, does not constitute a helpful error report. Educating operators to record full details of the circumstance in which a fault occurred is vital. This is not always easy but automatic diagnostic facilities in the form of abbreviated dumps can be built-in where appro- priate.

Controlling costs

Apart from ensuring that faults are remedied quickly, the other aspect of keeping users happy is, of course, controlling costs. A straightforward method of monitoring true costs is to allocate the programmer’s time against modification numbers, includ- ing corrections and general support. If a standard estimated time for a task is taken as, say, 5 ‘man’ days then any modification beyond this will be sub- ject to the project control system. Control of the cost factor through time spent on modifications is an important aspect of a planned ap-

proach. When things consistently take longer than expected it usually highlights a deeper problem than simply a series of particularly difficult changes.

Planning and motivating staff

Planning an efficient support opera- tion obviously does have its problems: gaining access to the machine is an inherent difficulty, especially with 24 hour systems or those with remote users. These problems, however, can usually be overcome by using bureau machines.

The problem of motivating staff, which is particularly important if a high standard of work is to be main- tained, is more difficult to solve. Here the larger organization has a definite advantage in being able to rotate its people through the support group so that noone need spend much more than a year on support work, unless they wish to do so. This avoids the feeling of being singled out for an unpopular assignment and emphasi- ses that support is an essential part of any DP operation. Being part of a dedicated support group also has the advantage that programmers can work on more than one system, thus extending their experience faster than would otherwise be possible.

In practice, new recruits to the company can do a spell in the support group before moving on to develop- ment or consultancy. The experience is accepted by most as a valuable opportunity to see large systems in their entirety and to gain an under- standing of the problems that can occur in user environments. With quick, effective training, staff can make the best use of their time in support and provide an efficient ser- vice, and the support work itself usually proves an effective training ground for programmers and analysts going on to more glamorous and prestigious projects - although few of them would admit it. Cl

Scicon Limited, 48 Berners Street, London Wll’ 4AQ, UK. Tel: 01-580 5599.

12 data processing