TQM and SW Maintanance

� � � � � � �

Assuming you have the piece of software that delivers the features required by your clients, how can you best deal with statements most frequently heard, such as:�

"The system is slow "�

"The quarterly processing was not completed on time, though in the March quarter it was".

Or, Your Systems manager's declaration "Your software started page faulting, adding memory improved response time."�

Or your whiz-kid programmer boasting: "It is tenfold Faster"

Or, at times, you enter into a contract specifying what the response time should be. The contract is based on a business transaction basis, e.g., "Finish 95% of the update-transactions within ten seconds in 97% of the days". Did you fulfil the contract?�

Or take your own question: - "Does the system behave differently now, then previously?"�

To satisfy yourself and your clients that you have fulfilled the terms of the contract you have to take into consideration changes of work load between days, changes in transaction mix and interaction of different systems. Your ability to objectively check these claims regarding response time, in a way that will be understood and accepted by your clients, is a key element of trouble shooting, never ending improvement, pride of workmanship, software evaluation and industrial peace.�

Management must measure performance objectively and draw conclusions from the collected data. Measurable parameters in the implementation stage in a system's life cycle are, for example, number of errors per function unit, delivery dates and budget. At the maintenance stage in a system's life-cycle response time is the parameter that should be managed, as response time is victim of the most frequent complaints, sensitive to software errors, an indicator of high consumption of other resources, sensitive to inefficient code and to demand fluctuation.�

PTA investigated the programs whose response times were worst during a hundred business days. PTA found that these programs were also the biggest CPU time, direct VO and buffered I/O consumers. Managing response time constrains never ending improvement on ISD, rather than meeting specifications that are set in concrete. PTA, thus, relates response time to quality of clients service and evaluates its service with the help of Statistical Process Control (SPC), implemented using DECtrace for VMS (Icnown by the acronym - 'EPC') as its data collector. PTA defined a number of business transactions of special interest ('event' in EPC terminology) such as Trade', 'Reversal' and 'Cheque Print'. EPC routine calls were placed, first, in the most frequently used pro- grams. Later, during maintenance, EPC service routines calls were placed in the rest of the programs.�

Currently, every change in the environment is evaluated on the basis of response time reports ("Yes, it is faster now" or: "The added functionality is worth the slower response time"). Three case studies, at the end of part 6 of this paper, will demonstrate real life usage of this technology.

�

� � � � � �

Hosted by www.Geocities.ws