Using general report format moderate margins Times New Roman

Using general report format (moderate margins. Times New Roman 12 font, single spacing), create a minimum of two page report. You should locate a case study from the internet where a large size software project has gone v/rung. Identify the project background, methods used for development, time and budget issues, and the evolution of problems. Following, in your own language, define the reason for failure; identify how this failure could have been avoided if possible. Reference all your use of Internet and/or other resources.

Solution

Knight Capital Group Loses Nine Figures in 30 Minutes

Knight Capital Group, a market-making firm that until August 2012 had a stellar reputation in its industry, blew all of that in about 30 minutes. Between 9:30 a.m. and 10 a.m. EST on August 1, the company’s trading algorithms got a little buggy and decided to buy high and sell low on 150 different stocks. By the time the bleeding had stopped, KCG had lost $440 million on trades. By comparison, its market cap is just $296 million and the loss was four times its 2011 net income.

What had happened?

Knight Capital’s worst day in IT started Wednesday morning with a test run of its new trading software SMARS. An old pal of mine who’s following the story closely (and is also deep in both IT and trading) told me that the company set up the software to work with only a few stocks. They also set the buy/sell points well outside where the markets were currently trading to ensure that nothing would actually execute.

Unfortunately, the trading algorithm the program was using was a bit eccentric as well. On every stock exchange, there is a \"bid\" and an \"ask\" price. The bid price is what you’d like to pay the holder of the stock if you want to buy their shares. The ask price is what they’ll pay to buy those same shares from you. There’s always a spread between the two prices, with the \"ask\" being a few cents or more above the \"bid\". If the stock is thinly traded, then the spread between the ask and the bid is higher than what you’d see for, say, IBM.

Knight Capital’s software went out and bought at the \"market\", meaning it paid ask price and then sold at the bid price – instantly. Over and over and over again. One of the stocks the program was trading, electric utility Exelon, had a bid/ask spread of 15 cents. Knight Capital was trading blocks of Exelon common stock at a rate as high as 40 trades per second – and taking a 15 cent per share loss on each round-trip transaction. As one observer put it: \"Do that 40 times a second, 2,400 times a minute, and you now have a system that’s very efficient at burning money\".

As the program continued its ill-fated test run, Knight’s fast buys and sells moved prices up and attracted more action from other trading programs. This only increased the amount of losses resulting from their trades to the point where, at the end of the debacle 45 minutes later, Knight Capital had lost $440m and was teetering on the brink of insolvency.

They may get at least a partial reprieve. The NYSE will reverse trades in six stocks during the time period when the prices were at least 30 per cent outside the normal trading range for the stocks. This will significantly defray much of Knight Capital’s losses for the day, but we don’t know if it’s enough to allow the firm to survive the blow.

Reason of Failure:

Software testing failed to capture and find the defect before production deployment. Software of this type can have regular enhancements, updates or patches applied nightly.  Some of these changes can be minor of nature, but should always be impact assessed for risk on all occasions. All changes must be taken very seriously and regulators within the financial services industry will push such agendas extremely hard.

4 Ways to Improve Software Testing and Reduce Risk

After the retrospective, your team may come up with a list of risks and issues such as those (theoretically) identified in the Knight Capital case. If so, consider these four techniques to reduce risk.

1.      Improve change and configuration management. Keeping test and production code in different \"sandboxes is one popular practice to reduce risk.

2.      Improve production monitoring. Lane suggests using automated processes to detect and send alerts regarding errors.

3.      View testing as a high-level risk management process. \"In many cases, trading companies feel there is not enough time for traditional testing due to the compressed time of these fleeting opportunities,\" Lane says. Ironically, many bugs would not be found by traditional testing, as they are configuration risks. The software may have worked correctly, but it in the wrong place, at the wrong time or from test code that was in production. The type of testers who \"click this, click that, make sure these numbers match,\" as Lane describes them, could not find such bugs. Better risk management is necessary.

4.      Increase internal controls on high-volume transactions. It is possible that the Knight Capital failure could have been averted by a single button that a human needed to click, especially when the volume reached a certain level. Such a control would not be at the program level but, instead at the public API level. Until such external controls exist, we would do well to build them into our gateway programs.