Each dimension interacts with the others in complicated ways that exacerbate project risks and problems and increase the likelihood of failure. Consider a simple software chore: a purchasing system that automates the ordering, billing, and shipping of parts, so that a salesperson can input a customer's order, have it automatically checked against pricing and contract requirements, and arrange to have the parts and invoice sent to the customer from the warehouse.
The requirements for the system specify four basic steps. First, there's the sales process, which creates a bill of sale. That bill is then sent through a legal process, which reviews the contractual terms and conditions of the potential sale and approves them. Third in line is the provision process, which sends out the parts contracted for, followed by the finance process, which sends out an invoice.
Let's say that as the first process, for sales, is being written, the programmers treat every order as if it were placed in the company's main location, even though the company has branches in several states and countries.
That mistake, in turn, affects how tax is calculated, what kind of contract is issued, and so on. The sooner the omission is detected and corrected, the better. It's kind of like knitting a sweater. If you spot a missed stitch right after you make it, you can simply unravel a bit of yarn and move on. But if you don't catch the mistake until the end, you may need to unravel the whole sweater just to redo that one stitch.
If the software coders don't catch their omission until final system testing—or worse, until after the system has been rolled out—the costs incurred to correct the error will likely be many times greater than if they'd caught the mistake while they were still working on the initial sales process.
And unlike a missed stitch in a sweater, this problem is much harder to pinpoint; the programmers will see only that errors are appearing, and these might have several causes. Even after the original error is corrected, they'll need to change other calculations and documentation and then retest every step. In fact, studies have shown that software specialists spend about 40 to 50 percent of their time on avoidable rework rather than on what they call value-added work, which is basically work that's done right the first time.
Once a piece of software makes it into the field, the cost of fixing an error can be times as high as it would have been during the development stage.
If errors abound, then rework can start to swamp a project, like a dinghy in a storm. What's worse, attempts to fix an error often introduce new ones. It's like you're bailing out that dinghy, but you're also creating leaks. If too many errors are produced, the cost and time needed to complete the system become so great that going on doesn't make sense.
In the simplest terms, an IT project usually fails when the rework exceeds the value-added work that's been budgeted for. This is what happened to Sydney Water Corp. According to an investigation by the Australian Auditor General, among the factors that doomed the project were inadequate planning and specifications, which in turn led to numerous change requests and significant added costs and delays.
Software project failures have a lot in common with airplane crashes. Just as pilots never intend to crash, software developers don't aim to fail. When a commercial plane crashes, investigators look at many factors, such as the weather, maintenance records, the pilot's disposition and training, and cultural factors within the airline.
Similarly, we need to look at the business environment, technical management, project management, and organizational culture to get to the roots of software failures. Chief among the business factors are competition and the need to cut costs.
Increasingly, senior managers expect IT departments to do more with less and do it faster than before; they view software projects not as investments but as pure costs that must be controlled.
Political exigencies can also wreak havoc on an IT project's schedule, cost, and quality. When Denver International Airport attempted to roll out its automated baggage-handling system, state and local political leaders held the project to one unrealistic schedule after another.
The failure to deliver the system on time delayed the opening of the airport then the largest in the United States , which compounded the financial impact manyfold. Even after the system was completed, it never worked reliably: it chewed up baggage, and the carts used to shuttle luggage around frequently derailed.
Eventually, United Airlines, the airport's main tenant, sued the system contractor, and the episode became a testament to the dangers of political expediency. A lack of upper-management support can also damn an IT undertaking. This runs the gamut from failing to allocate enough money and manpower to not clearly establishing the IT project's relationship to the organization's business. In , retailer Kmart Corp. Four months later, it declared bankruptcy; the company continues to struggle today.
Frequently, IT project managers eager to get funded resort to a form of liar's poker, overpromising what their project will do, how much it will cost, and when it will be completed. Many, if not most, software projects start off with budgets that are too small. When that happens, the developers have to make up for the shortfall somehow, typically by trying to increase productivity, reducing the scope of the effort, or taking risky shortcuts in the review and testing phases.
These all increase the likelihood of error and, ultimately, failure. This was the same group that had earlier built the hugely successful Sabre reservation system, proving that past performance is no guarantee of future results. After crash investigators consider the weather as a factor in a plane crash, they look at the airplane itself. Was there something in the plane's design that caused the crash?
Was it carrying too much weight? In IT project failures, similar questions invariably come up regarding the project's technical components: the hardware and software used to develop the system and the development practices themselves. Organizations are often seduced by the siren song of the technological imperative—the uncontrollable urge to use the latest technology in hopes of gaining a competitive edge.
With technology changing fast and promising fantastic new capabilities, it is easy to succumb. But using immature or untested technology is a sure route to failure.
Motor vehicle officials admitted that they got caught up in chasing technology instead of concentrating on implementing a system that met their requirements. The IT debacle that brought down FoxMeyer Drug a year earlier also stemmed from adopting a state-of-the-art resource-planning system and then pushing it beyond what it could feasibly do. A project's sheer size is a fountainhead of failure. Studies indicate that large-scale projects fail three to five times more often than small ones.
The larger the project, the more complexity there is in both its static elements the discrete pieces of software, hardware, and so on and its dynamic elements the couplings and interactions among hardware, software, and users; connections to other systems; and so on.
Greater complexity increases the possibility of errors, because no one really understands all the interacting parts of the whole or has the ability to test them. Sobering but true: it's impossible to thoroughly test an IT system of any real size. Roger S. Even a small line program with some nested paths and a single loop executing less than twenty times may require 10 to the power of 14 possible paths to be executed. All IT systems are intrinsically fragile.
In a large brick building, you'd have to remove hundreds of strategically placed bricks to make a wall collapse. But in a line software program, it takes only one or two bad lines to produce major problems. In , a portion of ATandamp;T's telephone network went out, leaving 12 million subscribers without service, all because of a single mistyped character in one line of code.
Sloppy development practices are a rich source of failure, and they can cause errors at any stage of an IT project. To help organizations assess their software-development practices, the U. It rates a company's practices against five levels of increasing maturity.
Level 1 means the organization is using ad hoc and possibly chaotic development practices. Level 3 means the company has characterized its practices and now understands them.
Level 5 means the organization quantitatively understands the variations in the processes and practices it applies. As of January, nearly government and commercial organizations had voluntarily reported CMM levels.
Over half acknowledged being at either level 1 or 2, 30 percent were at level 3, and only 17 percent had reached level 4 or 5. Clarke and R. Robert N. Charette Why Software Fails. Stephens, Beginning Software Engineering, B. Hochgurtel, Ed. Shende, A. Samitha Khaiyum, Dr. K Karibasappa Significance of failure avoidance in the software development process.
Stadler, J. Software failure modes and effects analysis. Song, J. A new software failure analysis method based on the system reliability modelling. Putnam-Majarian and D. Jatinderkumar R. Saini National Journal of computer science and technology. Volume: 04 Issue: 02 July — December — Zahid, A. As a purely intellectual product, it is among the most labor-intensive, complex, and error-prone technologies in human history.
Until the s, programmers were very meticulous in planning their code, rigorously checking code, providing detailed documentation, and exhaustive testing before the software is released to users.
However, as computer became widespread, attitudes changed. In this paper, we studied the various reasons why software fails. Our studies reveal that the major reasons why software fails are poor or no design at all, inadequate testing of codes, and attitudinal changes among programmers and other factors.
Related Articles:. Software Quality Assurance. Successful implementation of IT information technology projects is a critical strategic and competitive necessity for firms in all industrial sectors today. However, due to cost overruns, schedule … Expand.
Highly Influenced. View 5 excerpts, cites background. Reducing failures in software development projects: effectiveness of risk mitigation strategies. Risks as uncertain conditions with negative consequences on a software project could increase the failure rate of a project if it is ignored. To identify the effectiveness of risk management … Expand. Abstract Enterprises make great efforts to adopt up-to-the-minute technologies and completely new systems.
Despite these efforts, software projects outcomes are not successful.
0コメント