CHAPTER 6: Major Issues in Systems Development

 

“Our achievements speak for themselves. What we have to keep track of are our failures, discouragements, and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay.”

— Eric Hoffer
Reflections on the Human Condition, 1973

IN THIS CHAPTER, YOU WILL LEARN:

  1. Why “time to market” is a dominant issue today;
  2. The common solutions to speed up projects;
  3. Why productivity is a major issue;
  4. The common solutions to the productivity issue;
  5. The number of system defects, and “ good enough” quality; and
  6. The relationship between defects, and age of a systems.

As a systems analyst, you will be part of a team of people whose purpose is to develop a useful, high-quality information system that will meet the needs of the end user. As you carry out your work, you and your fellow project team members will undoubtedly find yourself influenced by the following major issues:

  • Time to market
  • Productivity
  • Reliability
  • Maintainability

6.1 TIME TO MARKET

6.1.1 Why is Time-To-Market so Important?

One of the most significant changes in the business environment during the past decade has been the increased emphasis on time to market. The first company to introduce a successful new product or service into the marketplace is likely to dominate that market if its competitors are unable to respond quickly with an equal or better offering. Note that this doesn’t mean that it’s imperative to be “first to market,” though that’s often an advantage, too. But there are also situations when the pioneer in a new market segment attracts the interest of the marketplace, but also receives criticisms for shortcomings or flaws in that initial offering. If a competitor observes the marketplace criticisms, and reacts quickly — within a matter of weeks, or a few months at most — with a cheaper, better, faster, smaller product, then it has a chance to compete effectively and gain valuable market share. But if the first company not only brings out its first product, but also its second and third versions, before the competition can get started, it has a good chance to grabbing the lion’s share of the market and keeping it.

In many cases, the first-to-market company is a small startup with an innovative idea, created by entrepreneurs who toil for long hours to build a prototype that will attract the interest of investors and venture capitalists. When the first “production” model is introduced into the marketplace, the startup company typically lacks the marketing resources, the manufacturing prowess, and the financial resources to be able to compete the industry “giants” in a head-on fashion. Their hope is that they can enter a new market niche, become established, and generate customer loyalty and brand-name recognition before the industry giants can respond.

In other situations, the industry giants are playing the same game against one another. They know that any new product or service is likely to be matched relatively quickly by a competitor that has equivalent marketing, manufacturing, and financial resources; the question is how quickly. In the 70s and 80s, a competitor might deliberately wait for a year or two, in order to see whether the new product was actually going to attract enough interest to make it worthwhile to compete; the assumption was that there would still be plenty of time to create a competitive product in an economy that still moved at a moderate pace. But as we moved into the 1990s, and more and more businesses and individuals began operating on “Internet time” [1], it became apparent that the luxury of waiting for a year or two to make a competitive response no longer existed. If you can afford the risk that the product will be a complete failure, or a short-term fad (e.g., like the hula hoop or the Pet Rock), then the best of all worlds is to be first-to-market, with an ability to create new, improved versions at a rapid pace; if you can’t afford to take that risk, then you have to be ready to respond to successful competitive product introductions as quickly as possible.

The reason this is so significant to systems analysts in the information technology industry is that a significant percentage of new products and services today involve complex hardware/software systems. In some cases, the system is literally embedded within the product itself — e.g., a new model of “smart” cell-phone introduced by vendors like Nokia, Qualcomm, and Samsung. In other cases, the system is needed to help support the engineering and development of a new product, with a faster “cycle time” than ever before. New models of airplanes, such as the Boeing 777, were designed almost entirely with the aid of computer simulations, eliminating the costly and time-consuming use of wind-tunnels to test the aerodynamic properties of a plywood model; similar computer-based technologies are being used to speed up the development of new models of automobiles.

Thus, the most obvious consequence of this new business imperative is that IT departments are being urged to develop their computer systems more quickly than ever before — because the computer system is often on the “critical path” for the overall product or service. But in addition, systems analysts are also being called up on to help analyze and re-design the “business processes” outside the computer system, which are necessary to support the product or service in the field. For example, there is enormous competitive pressure within the financial services industry to approve mortgage applications and car-loan applications more quickly than ever before — indeed, so quickly that an approval can be granted in response to a telephone call from a prospective customer, before the customer hangs up the phone. To accomplish this obviously requires a very efficient computer system; and that computer system must be developed sooner than a competitive financial institution can develop their own system. But in addition, it’s often necessary for the systems analysts to document and study all of the human processes, approvals, hand-offs, conversions (e.g., transcribing a customer’s verbal request for a $10,000 loan onto a handwritten scribbled note, and from there into a data-entry format to be keyed into a computer system), and transmittals (e.g., an clerical person carrying a form to the supervisor’s desk for approval or rejection); the resulting activity, which is often described as business process reengineering, is intended to eliminate redundant and unnecessary processes, and look for dramatically faster ways of carrying out the necessary processes.

6.1.2 How does the Time-To-Market Imperative Affect Systems Analysts?

The obvious conclusion from the discussion above is that everyone in a business environment is being pressured to work harder and faster, in order to develop new products and services more quickly, with the intention that those products and services will themselves be faster (and cheaper and smaller and better) than the products and services they replace. But aside from the obvious strategies of working a 10-hour day instead of an 8-hour day, and running from place to place within the office, rather than walking, what else does this time-to-market imperative mean for the systems analyst?

Quite simply, it means that there is less time available than ever before for end-users to articulate their requirements, and less time for the analyst to document those requirements, study them, and propose a new system. In many cases, the end-users a business people who feel the direct competitive pressure of the marketplace; as a result, they’re likely to exclaim, “I don’t know exactly what my requirements are, except that we’ve got to build something better than our competitors have just introduced, and we’ve got to get our version into the marketplace as fast as possible — yesterday, if not sooner!”

Articulating and documenting the system requirements is a time-consuming process in itself, but designing, coding, and testing those requirements is also time-consuming. [2] Thus, even if the systems analysis process was both perfect and instantaneous, there would still be enormous pressure placed upon the project team to implement those requirements within an extremely aggressive timetable. Indeed, the timetable is often so aggressive that it is simply impossible to implement all the requirements; it may be politically unpopular to state such a thing openly and directly, but the chances are that everyone on the project team — including the end-users, if they have gone through one or two of these high-pressure projects — will understand this reality.

Thus, another consequence of the time-to-market imperative involves not just “prioritization” of the requirements, but also a cold-blooded process of triage. The word “prioritization” implies that a very-important requirement “A” will be implemented before a less-important requirement “B,” but it also implies (in the absence of anyone saying something to the contrary) that all of the requirements will nevertheless be completely implemented by the time the deadline arrives. “Triage,” on the other hand, is a conscious acknowledgment that some of the requirements might not be implemented before the project team and the business user run out of time, and are forced — for competitive reasons — to introduce their product/service into the marketplace.

The concept of triage goes hand in hand with the concept of prototyping, which gradually became an accepted practice during the decade of the 1990s. The idea is familiar to almost everyone in the systems development field, too: rather than specifying, designing, coding, and testing an entire system, all at once, a prototyping approach involves specifying the basic features of the system, and the detailed requirements of a few of the most important features; an understanding of the overall basic features is then sufficient to design a basic “archictecture” for the system, along with the detailed characteristics of the first few important features that the user wants to see. That basic architecture is then implemented, along with a “rough” version of the first few features — typically without much attention to the subtleties of user-interface “bells and whistles,” and without much attention to security, backup, recovery, and other “operational” requirements that will eventually have to be added before the system can be put into full-scale operation.

The purpose of building the prototype, of course, is to demonstrate something “tangible” to the end-users, rather than a set of diagrams, models, and documents. There’s a good chance that the experience of “playing” with the prototype will help the users refine their ideas about what they really want. In the most extreme case, the prototype might demonstrate that the business benefits of the system are non-existent, in which case the project can be cancelled before large sums of money and time have been expended. And in the best case, the users will say, “That’s terrific! When can we have the rest of the features?”

Aside from the obvious benefit of refining and discovering the “true” requirements, the prototyping approach has the political benefit of demonstrating something tangible to the end-users, and thus giving them confidence that a reasonably useful subset of the entire list of features is likely to be finished in time for their deadline. The alternative is to spend a large percentage of the project schedule and resources attempting to document a “perfect” set complete requirements, and then hope that a period of frantic coding and testing will be sufficient to implement those requirements. Unfortunately, the day-to-day activities of analysis, which we’ll be discussing in great detail in Part II and Part III of this book, involve “intangible” activities of interviewing, writing documents, drawing diagrams, and holding meetings with end-users to ensure that their needs have been properly understood. It’s all legitimate work, but at the end of each day of such work, the end-users are likely to be frustrated that they don’t have a working system — or even a semblance of a working system — that they can see and touch.

Thus, many of our discussions in subsequent chapters of this book will remind you of the need to incorporate triage and prototyping into your activities as a systems analyst. Thus, you should be prepared for discussions which conclude by saying, “If you have all the time in the world, and your objective is to build a ‘perfect’ system, then you should do X, Y, and Z until you are satisfied that they are complete and correct.” But if you are under pressure caused by a time-to-market demand from the end-user, then you should still do X completely, but be prepared to carry out only a high-level version of Y, and defer Z entirely until some later time.

6.2 PRODUCTIVITY

Of course, everyone is in favor of productivity; it is a term used in the same manner as motherhood and loyalty to one’s country. But a generation ago, when most of today’s operational systems were being built, productivity was not something that anyone paid much attention to. Systems analysts and programmers in the 1970s and 1980s worked long hours (though not always predictable hours!), but no one was ever sure how much work they would accomplish in a week, or how long it would take to build an entire system. The general feeling was that the systems development team would work Very Hard every day, and one day — voila! magic! — the system would be finished.

Today, productivity is a much more serious issue. So is the issue of system quality: a system failure in a large, complex system is likely to have devastating consequences — especially if it is an on-line or Internet-based system with thousands of customers carrying out business transactions. And maintainability has become a major issue: it is now clear that many of the systems built today will have to last 20 years or longer before they can be rebuilt, and they will have to undergo constant revision and modification during their lifetime. [3]

6.2.1 Productivity: The Applications Backlog

One of the most visible problems facing the systems development profession today is that of productivity. Modern business and society seem to be demanding ever more: more systems, more sophistication, and everything more quickly, and at a lower cost. As a systems analyst, you will see two major aspects of this problem: one aspect is the backlog of new systems that need to be developed, and the other is the length of time needed to build any individual new system.

In almost any organization where there is a centralized group responsible for developing new systems, there is a backlog of work waiting to be done, ranging from several months to several years. [4] The backlog consists of three different kinds of systems:

  • Visible backlog: These are new systems that the users have officially requested and that have been approved by appropriate management committees. However, the projects have not been started because there are not adequate resources (i.e., systems analysts, programmers, funding, etc.).
  • Invisible backlog: These are new systems that the users know that they want, but have not bothered to ask for through “official” channels, because they are still waiting for projects in the visible backlog to be completed.
  • Unknown backlog: These are new systems that the users do not even know that they want yet, but that will be identified as soon as any of the systems in the visible and invisible backlog are finished.

In a classic study of the backlog and demand for information systems (Alloway and Quillard, 1982), MIT Sloan School researchers Robert Alloway and Judith Quillard found that the invisible backlog was typically 5.35 times larger than the visible backlog of new systems. This suggests that the backlog problem is very much like the proverbial iceberg: only a small portion is visible, with a large portion hidden under water. This is, of course, a major problem for the systems development organization that does its budgeting and planning based only on known, visible demands for its services.

A second aspect of the productivity problem is the length of time required to develop any individual system. [5] Obviously, if the average systems development project could be cut from two years to one year, or from six months to three months, the backlog problem would rapidly go away; but the point here is that users are generally concerned not only with the global problem of the backlog, but also the local productivity problem associated with an individual project. They worry that by the time the new system is built, business conditions will have changed so drastically that the original requirements will no longer be relevant.

Or, to put it another way, a new system is often associated with a business opportunity that the user perceives, and that business opportunity often has a window of opportunity, a time period after which the business opportunity will have disappeared and there will be no need for a new system. As we discussed in section 6.1, this “time-to-market” mentality sometimes dominates all other considerations in the development of a new system.

There is a third reason for the productivity problem in some organizations: some projects turn out to be dismal failures and are canceled by management before they are ever finished. Indeed, various surveys have found that as many as 25% of all projects in large IT organizations are never finished. There are many reasons, of course, why a project could fail: technical problems, managerial problems, an inexperienced staff, lack of time to do a proper job of systems analysis and design (which is usually a management problem), lack of involvement on the part of management or the users. For an excellent discussion of the reasons for project failures, see Robert Block's delightful The Politics of Projects (Block, 1980).

The productivity problem has existed in the systems development profession for a number of years, and many organizations are aggressively searching for ways to radically reduce their application backlog and cut the length of time required to develop a new system. Among the more commonly used techniques are these:

  • Hiring more programmers and systems analysts. This is particularly common in new, growing organizations, (e.g., an organization created as a result of a merger, or a new organization formed to exploit new markets and new businesses). [6] For mature organizations, though, this approach has generally been shunned; indeed, many organizations feel that they have too many programmers and analysts already and that the real job is to make them more productive. [7]
  • Hiring more talented programmers and systems analysts, and giving them superior working conditions. Rather than building a large army of mediocre systems developers, some organizations concentrate on creating a smaller group of highly talented, highly trained, well-supported (and presumably well paid!) professionals. This approach is based on the well-known disparity in performance among experienced computer programmers: as far back as 1968, a classic study (Sackman, Erickson, and Grant, 1968) first documented the fact that some computer programmers are 25 times more productive than others. An extreme form of this concept is the “superprogrammer,” or “chief programmer team” concept that was originally popularized by IBM in the 1970s — a project team of specialists (librarians, toolsmiths, language lawyers, etc.) supporting an extraordinarily talented professional who carried out both the systems analysis and the design and programming of the system (for more details, see (Brooks, 1995)). Of course, most organizations cannot build an entire systems development organization around a person ten times better than the average. [8] However, there is something to be said for building an organization with people twice as productive as the average analyst/programmer, even if those people have to be paid twice as much. And there is something to be said for making the existing staff as productive as possible by providing up-to-date training, modern software development tools (discussed in more detail later), and appropriate working conditions. [9]
  • Letting users develop their own systems. It is interesting to note that many other technologies interposed someone between the user and the technological device itself, during the developmental period of the technology: the automobile chauffeur and the telephone switchboard operator are two obvious examples. Of course, most of us don’t have chauffeurs and none of us need a telephone operator to place our calls for us; the automobile and the telephone are sufficiently user friendly that we can operate them ourselves. Similarly, the combination of personal computers, information centers, and “visual” programming languages, all introduced into many American organizations during the 1980s, has made it possible for many users (including, as we saw in Chapter 2, a generation of users who learned the fundamentals of computing in high school or college) to develop their own simple applications. Ad hoc reports, database inquiries, spreadsheet applications and certain “table-driven” maintenance changes to existing programs are among the projects that a computer-literate, motivated user can certainly do on her or his own.
  • Better programming languages. Programming languages have gone through enormous change since the 1950s, when programmers created computer programs by laboriously coding the binary 0s and 1s that the hardware executes. This first generation of machine language gave way to a second generation of assembly language in the 1960s, and third generation procedural languages in the 1970s; examples of 3rd-generation languages, which are still widely used, are COBOL, C, C++, and FORTRAN. While the software industry continues to improve these languages (e.g., the version of FORTRAN available today is vastly better than the version of FORTRAN used by programmers in the early 1970s), most of the focus has shifted to a new generation of “visual” programming languages that eliminates the need for the programmer to worry about messy, time-consuming details of input editing and validation, report formatting, and file handling; examples of these languages are Visual Basic, Delphi, PowerBuilder, and "visual" versions of C, C++, and even COBOL. In addition, a number of languages have emerged for developing Internet-based applications; these include Java, PERL, PYTHON, and others. Many proponents argue that these new languages can increase the productivity of the programming activity by as much as a factor of ten; however, since programming typically represents only 10% to 15% of the overall systems development project, the overall productivity gain is often much less substantial.
  • Attacking the maintenance problem. Maintenance is a major issue in the systems development field, as we will discuss in Section 6.4. However, most of the attention is currently focused (as one might expect) on the maintainability of new systems; meanwhile, as mentioned above, many organizations are still devoting 50% to 75% of their resources to maintaining old systems. So the question becomes: what can be done to make these old systems easier to maintain, aside from the obvious idea of throwing the old systems away and building new replacements? [10] One approach growing in popularity is that of restructuring — mechanically translating the old programs (whose program logic has been patched and changed so many times that it is often completely unintelligible) into new, well-organized, structured programs. A related idea is the use of automated documentation packages that can produce cross-reference listings, data dictionaries, detailed flowcharts, structure charts, or system flowcharts directly from the program (this is referred to by some maintenance people as reverse engineering). Another approach, as mentioned above, is to encourage users to make their own maintenance changes. [11] Still another approach is to carefully document the specific nature of the maintenance work: it often turns out that as little as 5% of the code in an operational system is responsible for 50% or more of the maintenance work.
  • Software engineering disciplines. Still another approach to improved productivity is a collection of tools, techniques, and disciplines generally known as software engineering — or sometimes described in more specific terms as “structured techniques” or “object-oriented techniques.” These include structured programming, or object-oriented programming; structured design (SD) or object-oriented design (OOD); and structured analysis (SA) or object-oriented analysis (OOA) [12] as well as such related disciplines as software metrics [13], software reuse, and software quality assurance. Retrospective studies have shown that, in general, the structured techniques typically had a modest impact, typically a 10% to 20% improvement, on the productivity of the systems development professionals during the development phase of the project; object-oriented techniques have typically had a somewhat larger impact on productivity, largely because of the increased emphasis on software reuse. However, systems developed using structured- and object-oriented techniques generally have substantially lower maintenance costs and substantially higher reliability, often as much as a factor of 10 or more. This tends to free up resources that would otherwise be used for maintenance or bug-fixing, thus improving the productivity of the overall organization.
  • Automated tools for systems development. Finally, we observe that one reason for the productivity problem is that much of the work of developing an automated information system is, ironically, carried out in a manual fashion. Just as the cobbler’s children are the last to get shoes, programmers, systems analysts, and project managers have traditionally been the last to get the benefits of automation for their own work. Of course, one could argue that a compiler is an automated tool for programming, just as testing packages and debugging aids provide some form of automation. But, until recently, there has been little automated assistance for the systems designer and almost nothing for the systems analyst; similarly, there have been very few tools to assist the project team in carrying out the details of the software “life cycle” that they have chosen for their project. Now there are a number of development tools that can automate much of the drudgery of developing and maintaining the graphical models associated with object-oriented and structured development that we saw in Chapter 4; these automated tools also perform a variety of error-checking activities, thus ensuring that the specification produced by the systems analyst is complete, unambiguous, and internally consistent. And, in some cases, the automated tools can even generate code directly from the specification, thus eliminating the manual activity of programming altogether. Details of these automated tools for systems analysis are discussed in Appendix A.

Many of these productivity approaches can be used together, for they involve complementary concepts and techniques. Individually, each approach discussed above might lead to a 10% to 15% improvement; taken together, they can easily double the productivity of the organization and, in special cases, perhaps improve productivity by a factor of ten. An excellent discussion of the quantitative impact of these and a large number of productivity factors can be found in (Jones, 1986).

As a systems analyst, your reaction to all of this might be, “So what? Why is this relevant?” Indeed, it does seem that many of the productivity issues are in the province of programming, testing, and maintenance — none of which are in the province of systems analysis. Nevertheless, there are three reasons why you should be very sensitive to the issue of productivity as a systems analyst:

  1. The quality of work performed by the systems analyst can have a tremendous impact on the productivity of the systems designer and programmer; it can also have a tremendous effect on the amount of time spent testing, since 50% of the errors (and 75% of the cost of error removal) in a system are usually associated with errors of systems analysis. The programmers may get blamed for low productivity because of the amount of time they spend testing, but this is often an indication of low-quality work done by the systems analyst.
  2. Some of the productivity techniques — more people, better people, better working conditions, and especially automated tools — are of direct relevance to the systems analyst. It is worth your while to think about what could be done to make you and your job more productive.
  3. The productivity of systems analysis is a politically sensitive issue, because it often appears to the user (and sometimes to managers within the systems development group and in other parts of the organization) that very little is happening during the systems analysis phase; one often hears the comment, “So when are you people going to start writing the programs? We can’t afford to sit around forever talking about the system, we need to get it implemented!” And the product of systems analysis, the functional specification, is not given much value by the users; the reaction to the specification will sometimes be, “What’s the big deal with all these pictures and words? We told you what we want the system to do; why did you have to write all of this stuff?”

The fact of the matter is that you can’t build a successful, high-quality, maintainable system if you don’t know precisely, and in sufficient detail, what it is supposed to do. So, while some users and managers may complain that systems analysis is merely a period of “resting up” while getting ready for the real work of the project (programming), the fact is that it must be done carefully and rigorously. But it must also be done with as much efficiency and productivity as possible; so it behooves the systems analyst not to think that productivity is just a programming issue!

6.3 SOFTWARE QUALITY AND RELIABILITY

A second major problem facing systems developers is that of software quality and reliability. The enormous amount of time spent on testing and debugging, typically 50% of a systems development project, and the enormously low productivity (which many feel is related to the amount of time spent on testing) might be acceptable if the result were highly reliable, easily maintainable systems. The evidence of the past 40 years is just the opposite: the systems produced by organizations around the world are riddled with errors and are almost impossible to change.

“Riddled with errors” means different things to different people. On average, software developed in American organizations has between three and five errors for every hundred program statements — after the software has been tested and delivered to the customer; see (Jones, 1994). Organizations with higher levels of quality can reduce defects to as few as few as 3-5 errors for every 10,000 program statements, and a very few organizations claim they have reduced defects to as few as 3-5 errors per million statements. On the other hand, there have been pessimistic reports, such as (Sanger, 1985), suggesting that American software may have as many as three to five errors for every ten program statements!

Software errors range from the sublime to the ridiculous. A trivial error might consist of output (results) that are correct, but not printed or formatted quite as neatly and tidily as the user desires. A moderately serious software error might include a case where the system refuses to acknowledge certain kinds of inputs, but the end user can find some way to circumvent the problem. Alternatively, a moderate software error might cause some work to be lost, but the input data can be re-entered, and the program can be re-executed within an hour or two; this is an experience that almost everyone has had with a personal computer whose word processor has crashed and destroyed an hour’s worth of work. On the other hand, serious errors are those that cause the entire program to stop working, with an associated major loss of money or human life [14]. Examples of some serious software-related errors that have been documented over the years include the following assortment:

  • In 1991, various metropolitan areas experienced serious outages of telephone service — including Washington, DC (with 6.7 million lines), Los Angeles and Pittsburgh (with 1 million lines each) — that were eventually traced to a untested patch involving just a few lines of code in the Signaling System 7 computer system.
  • In 1992, a Royal Air Force pilot accidentally dropped a practice bomb on the flight deck of the Royal Navy’s most modern aircraft carrier, the Ark Royal, missing its intended target by hundreds of yards, and injuring several sailors. The cause was attributed to a timing delay in the software intended to target an object at a parametrically specified offset from the tracked object — i.e., the aircraft carrier.
  • In 1993, the planned launch of the Columbia space shuttled had to be scrubbed at the last minute because of a “glitch in the computer system designed to ensure safety on the ground during launches.”
  • In 1994, two U.S. Army UH-60 Black Hawk helicopters were shot down by two American F-15C fighter planes in the no-fly zones over northern Iraq, in broad daylight, and in an area that had not seen Iraqi aircraft for several months. The cause remains murky, but appears to be a combination of human error and hardware errors, despite elaborate precautions designed to prevent such occurrences.

Unfortunately, the list goes on and on; see (Neumann, 1995) for examples. When the first edition of this book was being written in the late 1980s, there was widespread concern that software errors of this sort could lead to grievous consequences with the Star Wars program proposed by the U.S. Defense Department under the Reagan administration, or with some of the other major, complex software-controlled air defense systems; see (Jacky, 1985) and (Adams and Fischetti, 1985) for a discussion. Indeed, even if the reliability of the proposed Star Wars software had been 100 times better than that of average systems, it could still have had as many as 10,000 errors — hardly a reassuring prospect when any one of those errors could have obliterated life on this planet! By contrast, there are widespread (though unconfirmed) reports that some of the popular desktop operating systems had as many as 5,000 known defects when they were released to the marketplace; but since the consequences of those defects were relatively minor, the marketplace accepted the operating system as “good enough.”

In many cases, nobody is quite sure how many errors a system has because (1) some errors are never found before the system expires of old age, and (2) the process of documenting and recording errors is so slipshod that half of the errors that are found are not reported, [15] even within the systems development organization. In any case, the typical phenomenon of error discovery, over the period of several years of useful life of a software system usually takes the form shown in Figure 6.1.

The shape of this curve is influenced by a number of factors. For example, when the system is first released to the end users, they are often unable to put it into full-scale production; it takes them some period of time to convert their old system (which may have been a manual system) and to train their operational staff. Also, they are a little wary of the computer, and don’t want to push it too hard, so not many errors are discovered. As they convert their old operation over to the new system, as their operational staff is better trained, and as they lose their feeling of intimidation, they begin to push the software much harder, and many more bugs are found. [16] Of course, if this continued indefinitely — more and more bugs found each day — the users would eventually stop using the software and throw it away. In most cases, the programmers are frantically fixing new bugs as users discover them. In most cases, there comes a time when the system begins to stabilize and the users find fewer and fewer bugs.

There are three depressing aspects of Figure 6.1. First, the curve never returns to zero; that is, we almost never find a situation where time goes by without any new errors being discovered. Second, the area underneath the curve, which represents the total number of errors discovered over time, is atrociously high; it averages three to five errors for every hundred program statements. And third, the curve eventually begins rising again — usually after several years, but sometimes after only a few months. Eventually, all software systems reach such a state of crazy-quilt patchwork that any effort to fix one error will introduce two new errors, and the changes required to fix those two errors will introduce four new errors, and so on.

Figure 6.1 : Errors discovered as a function of time

There is one last problem to point out about software errors: they aren’t easy to fix. When someone, either the programmer, the end user, or some other intermediary, discovers that the software is not working properly, two things must happen: (1) the programmer must identify the source and nature of the error, and (2) he or she must find a way of correcting the error (either by changing some existing program statements, removing some statements, or adding some new statements) without affecting any other aspect of the system’s operation. This is not easy to do; in fact, the programmer has less than a 50% chance of success on the first attempt, and the odds drop rapidly if the programmer has to modify more than 10 to 20 program statements (see (Yourdon, 1986)).

6.4 MAINTAINABILITY

The correction of ongoing errors is one aspect of maintenance; Lientz and Swanson (Lientz and Swanson, 1980) found that it accounted for approximately 21% of the overall maintenance effort in American data processing organizations. [17] Maintenance also entails modification of a system to reflect changes in the hardware, modifications to speed up certain operational aspects of the system, or modifications to reflect a change in the end user’s requirements of the system.

Software maintenance is a major problem for most organizations; between 50% and 80% of the work done in most systems development organizations is associated with the revision, modification, conversion, enhancement, or debugging of a computer program that someone else wrote long ago. And it is expensive work; in the early 1970s, the U.S. Defense Department reported that the cost of developing computer programs on one project averaged $75 per computer instruction; the cost of maintaining the system ran as high as $4,000 per instruction.

To put this into even more vivid terms, consider the following examples from the U.S. Social Security Administration:

  • Calculating the cost-of-living increase for 50 million recipients of Social Security benefits takes 20,000 hours of computer time on older computer systems within the Social Security System (see (Rochester and Gantz, 1983)).
  • When the Social Security System upgraded its computer systems in 1981 from five-digit checks to six-digit checks, it required 20,000 person-hours of work and 2500 hours of computer time to modify 600 separate computer programs.
  • The morale in the Social Security maintenance department was so bad at one point that one of the programmers was caught urinating on a disk pack in the computer room. While this is certainly a novel way of venting one’s frustration, it’s not very good for the disk pack.

The result, in more and more IT organizations, is that existing systems that were built 10 or 20 years ago simply cannot be modified to meet the new demands of the government, or the economy, or the weather, or the fickle mood of the user. As our companies and our society become increasingly dependent on computers, we will find an interesting parallel: to the extent that the software stagnates, the company or society served by the software will stagnate.

The problem is even worse than this. If it were simply a case of the software being bad, we could consider throwing it away and replacing it. But many organizations have never capitalized their software (the costs are expensed each year), and their accounting and business policies make it prohibitively expensive to replace ancient systems. And there is an even more fundamental problem: in most organizations, there is no coherent description of what the systems are supposed to do. Whatever documentation exists is almost always obsolete and confusing. In any case, it provides, at best, some idea of how the software works, but not what its underlying purpose is or what business policy it is supposed to implement.

Thus, even though one could argue that maintainability is entirely a function of implementation (i.e., something for the programmers to worry about), it’s impossible to maintain a system if there is no accurate, up-to-date model of system requirements. This, ultimately, is the job of the systems analyst; as we will see in Chapter 8, functional specifications developed by systems analysts have gradually progressed from absolutely unmaintainable Victorian novels (thousands of pages of narrative text) to hand-drawn graphical models of the system, to computer-generated and computer-maintained models. We will also discuss the issue of ongoing maintenance of system specifications in Chapter 24.

6.5 OTHER ISSUES

What does the systems analyst have to worry about besides productivity, reliability, and maintainability? Well, the list varies from organization to organization and from project to project, but it usually includes the following:

  • Efficiency. A system must operate with an appropriate throughput (usually measured in transactions per second) and with an acceptable response time for on-line terminals. This is not usually an issue for the systems analyst to worry about, since the designers and programmers will have the most influence on the overall efficiency of the implemented system. Indeed, it is becoming less and less of an issue for modern systems, since computer hardware costs continue to decline each year, while the power and speed of computer hardware continues to increase steadily. [18]
  • Portability. Most new systems are implemented on one specific hardware/software platform (e.g., an Intel CPU and the Micorosoft Windows operating system), but there may be a need to develop the system in such a way that it can be easily moved to different hardware/software platforms. Again, this is not usually an issue for the systems analyst to worry about, though she or he may need to specify the need for portability in the implementation model. Obviously, it becomes a more significant issue during the design and implementation of the system; this is one reason why languages such as Java have become popular in recent years.
  • Security. Since modern computer systems are more and more accessible (because they tend to be on-line), and since they are responsible for managing more and more sensitive assets of the organization, security is becoming a major issue for many systems development projects: the new system must prevent unauthorized access, as well as unauthorized updating or deletion of sensitive data.
  • Usability. Assuming that a system has been designed with appropriate functionality, maintainability, portability, efficiency, and security, there is still a risk that the end-users may find it “user-hostile.” This is particularly relevant during the first decade of the 21st century, when numerous Internet-based systems are being marketed to a broad spectrum of consumers, many of whom are barely computer-literate enough to log onto the Internet. Because of the nature of such systems, there are not likely to be any detailed user-manuals available, nor is there an opportunity to provide detailed training to the user community before they begin accessing the system. Thus, the system has to be carefully designed from the very beginning to be highly intuitive, and extremely “user-friendly.” Vendors like Apple Computer have been focusing on this issue since the introduction of the Macintosh in the mid-1980s (see (Tognazzini, 1992) for a good discussion); more recent work has focused particularly on Internet-based computers and the broad spectrum of consumer-oriented users (see (Constantine and Lockwood, 1999) for a good discussion).

6.6 SUMMARY

Various experts predict that computer hardware price/performance ratios will continue to improve by a factor of 1,000 and possibly by as much as a factor of 1 million, within the next 10 to 15 years [19]. Unfortunately, the history of software development over the past three decades would lead the average observer to conclude that software technology will only improve by a modest amount. Since software has now become the major cost and the “critical path” of most systems, such a modest improvement cannot be considered acceptable. Throughout the computer industry, there is a massive, concerted effort to bring about order-of-magnitude improvements in the software development process. The systems analysis techniques presented in this book are part of that effort. As we have seen, part of the effort is an issue of programming and systems design; but a good system specification is the foundation, the bedrock, on which design and programming must rest.

REFERENCES

  1. Robert Alloway and Judith Quillard, “User Managers’ Systems Needs.” CISR Working Paper 86. Cambridge, MA: MIT Sloan School for Information Systems Research, April 1982.
  2. Harold Sackman, W.J. Erickson, and E.E. Grant, “Exploratory Experimental Studies Comparing Online and Offline Programming Performance.”Communications of the ACM, January 1968, pp. 3-11.
  3. Edward Yourdon, Managing the Structured Techniques: Strategies for Software Development in the 1990s, 3rd ed. New York: YOURDON Press, 1986.
  4. Bennett P. Lientz and E. Burton Swanson, Software Maintenance Management. Reading, MA: Addison-Wesley, 1980.
  5. T. Capers Jones, Programming Productivity. New York: McGraw-Hill, 1986.
  6. T. Capers Jones, “A Software Productivity Survey.” Speech at First National Conference on Software Quality and Productivity, Williamsburg, VA, March 1985.
  7. Edward Yourdon, op cit.
  8. F.T. Baker, op cit.
  9. David Sanger, “Software Fears on Star Wars.”New York Times, July 4, 1985.
  10. Jonathan Jacky, “The Star Wars Defense Won’t Compute.”Atlantic Monthly, June 1985.
  11. John A. Adams and Mark A. Fischetti, “Star Wars — SDI: The Grand Experiment.”IEEE Spectrum, September 1985, pp. 34-64.
  12. New York Times article on or around September 16, 1986, commenting on the number of errors in Star Wars.
  13. Dines Hansen, Up and Running. New York: YOURDON Press, 1984.
  14. Edward Yourdon, op cit.
  15. Bennett P. Lientz and E. Burton Swanson, op cit.
  16. Jack Rochester and John Gantz, The Naked Computer. New York: William Morrow, 1983.
  17. Edward Yourdon, Nations at Risk. New York: YOURDON Press, 1986.
  18. Robert Block, The Politics of Projects. New York: YOURDON Press, 1981.
  19. Steve McConnell, Rapid Development: Taming Wild Software Schedules. Redmond, WA: Microsoft Press, 1996.
  20. John Connell and Linda Shafer, Object-Oriented Rapid Prototyping. Englewood Cliffs, NJ: Prentice Hall, 1995.
  21. Fred Brooks, The Mythical Man-Month, 20th anniversary edition. Reading, MA: Addison-Wesley, 1995.
  22. Capers Jones, Assessment and Control of Software Risks. Englewood Cliffs, NJ: Yourdon Press/Prentice Hall, 1994.
  23. Nancy G. Leveson, Safeware — System Safety and Computers: A Guide to Preventing Accidents and Losses Caused by Technology. Reading, MA: Addison-Wesley, 1995.
  24. Peter G. Neumann, Computer-Related Risks. Reading, MA: Addison-Wesley, 1995.
  25. Bruce Tognazzini, Tog on Interface. Reading, MA: Addison-Wesley, 1992.
  26. Larry L. Constantine and Lucy A.D. Lockwood. Reading, MA: Addison-Wesley, 1999.
  27. Dietrich Dörner, The Logic of Failure: Recognizing and Avoiding Failure in Complex Systems. Reading, MA: Addison-Wesley, 1996.
  28. Robert B. Grady and Deborah L. Caswell, Software Metrics: Establishing a Company-Wide Program. Englewood Cliffs, NJ: Prentice Hall, 1987.
  29. Robert B. Grady, Practical Software Metrics for Project Management and Process Improvement. Englewood Cliffs, NJ: Prentice Hall, 1992.
  30. Gerald M. Weinberg, Quality Software Management, Volume 2: First-Order Measurement. New York: Dorset House, 1993.
  31. James Highsmith III, Adaptive Software Development. New York, Dorset House, 1999.

QUESTIONS AND EXERCISES

  1. Examine the financial report for a large, publicly owned company to see if you can determine how much is spent on systems development. How much money would be saved if the productivity of the systems development organization could be doubled?
  2. Pick a large, publicly owned company that is obviously dependent on computers for their day-to-day operation. Estimate how many days, weeks, or months the organization could continue to function if its computer systems stopped working.
  3. What are the three major issues in systems development today?
  4. Why is productivity likely to be the most visible problem in systems development today?
  5. What are the three types of backlog that can be found in a typical organization?
  6. Research Project: Conduct a survey in your organization to find out how large the systems development backlog is. Is the figure well known among the users and managers in your organization?
  7. What is the difference between a visible and and invisible backlog?
  8. Why is there an unknown backlog?
  9. Why is the invisible backlog likely to be much larger than the visible backlog?
  10. What are the seven common solutions that organizations are pursuing to solve their productivity problems? Can you suggest any others?
  11. How do you think an organization should measure the productivity of its systems development organization?
  12. How practical is it to solve the productivity problem by hiring more programmers or systems analysts? What are the advantages and disadvantages?
  13. Do you think it is practical to solve the productivity problem by hiring more talented programmers or systems analysts? Why or why not?
  14. Suppose there was a programmer ten times more productive than an average programmer earning $25,000 per year. Do you think management in a typical organization would be willing to spend $250,000 per year for the talented programmer? Do you think they should be willing? Why or why not?
  15. How practical do you think it is to solve the productivity problem by letting users develop their own systems? What are the advantages and disadvantages?
  16. What type of system development projects are most appropriate for users to develop on their own? What percentage of projects do you think is likely to fall into this category in a typical organization?
  17. How practical do you think it is to use new programming languages, either third generation languages like Ada or fourth generation languages like Focus, RAIT, and NOMAD, to solve the productivity problem? What are the advantages and disadvantages of this approach?
  18. Research Project: How much would productivity be improved in your organization during the next five years if the organization began using a new programming language? How is this affected by existing code and the existing “culture” of computer programmers and systems analysts?
  19. Why does a fourth generation programming language provide a productivity improvement over a conventional third generation programming language?
  20. How much would productivity in a typical organization be improved if maintenance could be reduced by a factor of ten?
  21. Research Project: Use a commercial “structuring engine” product to restructure an existing computer program in your organization, and measure the reduction in maintenance costs. What does this tell you about the potential benefits of a structuring engine?
  22. Do you think that restructuring can turn bad programs into good programs? Why or why not? If your answer is no, then what is the purpose of restructuring programs?
  23. Can users perform their own software maintenance? What is required to make this work? What percentage of software maintenance work do you think, realistically, users could actually do?
  24. Why can software engineering improve productivity?
  25. Why can automated software development tools improve productivity?
  26. How can the work done by a systems analyst affect the productivity of a systems development project?<