Designing supportability into software

Abstract

Background: Despite the identification of a "software crisis" in the 1960s, large software projects are full of defects even today [19]. These defects cause the software to behave unexpectedly. The cause generally is attributed to the inherent property of software to possess arbitrary complexity [20]. Additionally, computer software is becoming all pervading. There is literally an explosion of software automating things that were considered impossible to automate only a few years ago. Essentially, software is growing to encompass anything and everything with such speed that we don't have the time to reflect on 'what happens when the software does something that it was not intended to do?' In other words, the software encounters an anomaly or a defect something customers encounter everyday. In any case, whenever customers encounter problems caused by defects they need help to solve these problems. They generally seek such help at a software vendor's product support services. With software getting more and more complex it is getting extremely difficult to support customers in a timely and cost effective manner. There is a constant struggle to ensure high Quality of Service (QoS) with low Total Cost of Ownership (TCO), which in turn affects Return on Investment; in such a scenario considering nearly 80% of the costs associated with software occur after it is shipped to the customer. Currently, there are two solutions to such problems caused by defects: First, if the source of the problem itself is found to be a defect in the software then the software vendor generally fixes the problem by modifying their code. Such a problem is generally classified as a bug. By now it is known that software applications have such bugs or defects or anomalies. These bugs cause the software to behave unexpectedly. Depending on its severity this behavior can on one extreme go unnoticed or one the other end produce catastrophic results. It pervades all software whether it is the AT&T long distance switching node crash in 01/15/90, the well known Y2K bug in database related software, Microsoft Passport Security defect, Mars Polar Lander defect, or the Ariane 5 rocket defect. These are just a few examples of well known software bugs. For each well known bug there are untold numbers of bugs that may not see the limelight. These defects can arise due to many reasons during the design and development of the software however they primarily arise due the essence of software to possess inherent properties of complexity, conformity, changeability, and invisibility [20]. Hence, a question arises, "Do we still try to single-mindedly go for the elusory 0 bug product? OR Do we accept that there are going to be bugs and try incorporate / accommodate for this directly into the product or otherwise?" Second, if the source of the problem is such that the vendor cannot simply fix the product, then it is classified as a limitation of the software product itself. In such a case the support organization works with the customer to find a workaround. Additionally, if many customers encounter the same problem then the product needs to be modified based on the workarounds their support services have provided to customers. In other words the product evolves based on how its customers use it. Product support services also receive numerous problems that are non-defect related where the source could be customer error or ignorance, improper documentation etc and their solutions generally require end-user education and training, better documentation etc. However such nondefect related support incidences fall outside the scope of this thesis. In the defect related scenarios illustrated above most of the contemporary efforts to determine the root cause of a customer's problem, requires in-depth knowledge of the product, extensive debugging that is extremely tedious, painstaking, and manual. Resolution of a problem depends solely on the troubleshooting skills, experience and subjectivity of the Support Personal that the customer is able to get a hold of. Products have all along incorporated functionality such as better features, performance, scalability etc. into their designs however none explicitly addresses how to tackle a software application's problems. This is unfortunate since such problems deeply affect customers and software development organization alike. The former looses productivity, effectiveness, time and money while the latter expends dedicated monetary and human resources for troubleshooting software products for a number of years until the product is declared obsolete or the customer's license expires. Problems affect overall customer satisfaction with the software making them more skeptical of future releases. The bottom-line is that there is a strong need to innovate software design and development itself to address how to deal with software problems so that customers should not have to loose their time, money or their life because the software application they are using has problems.