[Gibbs94] Gibbs, W. Wayt, "Software's Chronic Crisis," Scientific American, September 1994, also in Software Engineering, M. Dorfman and R. H. Thayer (eds.), IEEE Computer Society Press, Los Alamitos, CA, 1997, pp. 4-12.
Hedsor Park NATO conference-London
to analyze the
Future Direction of Software
April 1993
• Conclusions of 22 leaders in software development from academia, industry, and research labs:
"We will see massive changes [in computer use] over the next few years, causing the initial personal computer revolution to pale into comparative insignificance"
"In 1968 we knew what we wanted to build but couldn't. Today we are standing on shifting sands."
[Cliff Jones, Professor at U. of Manchester]
[Read more on previous meeting -- Naur, P., and B. Randall (eds.),Software Engineering, Report on October 1968 Meeting, NATO Science Committee, Brussels, Belgium, 1969.]
[Gibbs94]
Hedsor Park NATO conference-London
to analyze the
Future Direction of Software
April 1993
• On programmers' assumption of accept-ability of defects in software products:
"When computers are embedded in light switches, you've got to get the software right the first time because you're not going to have a chance to update it."
[Mary Shaw, Professor at Carnegie Mellon]
[Gibbs94]
Hedsor Park NATO conference-London
to analyze the
Future Direction of Software
April 1993
• On scaling up of real-time systems:
"It is not clear that the methods that are currently used for producing safety-critical software, such as nuclear reactors or in cars, will evolve and scale up adequately to match our future expectations. On the contrary, for real-time systems I think we are at a fracture point."
[Gilles Kahn, sci. director of France's INRIA reseach lab]
[Gibbs94]
Hedsor Park NATO conference-London
to analyze the
Future Direction of Software
April 1993
• On System Integration:
"there is a better word than integration, from old Royal Air Force slang: namely, 'to graunch,' which means 'to make to fit by the use of excessive force.' "
[Brian Randell, U. Newcastle upon Tyne]
[Gibbs94]
Hedsor Park NATO conference-London
to analyze the
Future Direction of Software
April 1993
• On Distributed Systems :
"Distributed systems can consist of a great set of interconnected single points of failure, many of which you have not identified beforehand. The complexity and fragility of these systems pose a major challenge."
[Brian Randell, U. of Newcastle upon Tyne]
[Gibbs94]
Hedsor Park NATO conference-London
to analyze the
Future Direction of Software
April 1993
• Complexity is growing
There is "an order of magnitude growth in system size every decade--for some industries, every half-decade." Program-mers will have to change the way they work to keep up with this pace. "You can't build skyscrapers using carpenters."
[Bill Curtis, consultant to Software Engineering Institute]
[Gibbs94]
Complexity
Traditional processes for software development break down when a system becomes too complex for one manager to comprehend the entire system.
[Gibbs94]
Large-Scale Software
Failure Statistics
• For every six new large-scale software systems put into operation, two are canceled.
• The average software development project overshoots its schedule by half. Larger software development projects do worse.
• Three quarters of all large systems are "operating failures" that either do not function as intended or are not used at all.
[Gibbs94]
Federal Aviation Administration (FAA)
Advanced Automation System (AAS)
the new air traffic control system
• By 1994 the ten year effort required
• 1 million lines of code
• distributed over 100s of computers
• code embedded into new hardware
• round-the-clock response
` • handle unpredictable real-time events
• any error was a potential threat to public safety
• FAA hired respected software dev. leader, IBM Federal Systems Company (now Loral)
• did not use state-of-the-art technique for estimating cost and length of project.
• did not screen requirements and design drawn up for the system to catch mistakes early.
• estimated $500/line of code (5x industry average) for a well-managed development process
• AAS cost in 1994, $700-$900/line, on average every line had to be written twice.
• FAA administrator David R. Hinson in June 1994, because of cost overruns and unreliability of system, canceled two of the four major parts of the AAS and scaled down the 3rd.
• $144 Million had been invested in the failed parts.
• $1.4 Billion for new air-traffic controllers' workstation is now $1 billion over budget. Carnegie Mellon and MIT were contracted to see whether to cancel 4th part.
[See G. Stix, "Aging Airways," Scientific American, May 1994]
[Gibbs94]
Software-related failure of
the Baggage System at the
New Denver International Airport
Airport - twice the size of Manhattan, 10 times the breath of Heathrow. Initially scheduled to open October 1993, a year later airport planners could not predict when the baggage system designed by BAE Automated Systems would stabilize enough for the airport to open
Subterranean baggage-handling system
• designed to route and deliver luggage
between counters, gates and claim areas
• 21 miles of steel track,
• 4,000 independent "telecars"
• 20 different airlines,
• 100 networked computers,
• 5,000 electronic sensors,
• 400 radio receivers,
• 56 bar-code scanners
• $193M initial cost estimate
• cost increasing $1.1M/day in interest
and operating costs
[Gibbs94]
Real-Time System
Software Related Failure of the
Clementine Department of Defense Satellite
• Mission was to test targeting software for future use in a space-based missile defense system
• Department of Defense applied rigorous testing standards to ensure reliability of mission-critical software.
• A bug in the software caused the satellite to fire maneuvering thrusters incorrectly, run out of fuel, lose maneuverability and miss rendezvous with asteroid Geographos.
• Real-time systems errors are hard to find and reproduce because they occur only when under certain conditions.
[Described in more detail in B. Littlewood and L. Strigini, "The Risks of Software," Scientific American, November 1992.
[Gibbs94]
California's Department of Motor Vehicles System Integration Failure
• In 1987 the California Department of Motor Vehicles decided to "simplify" its system and implement one-stop renewal kiosks within a five year period by merging the state's driver registration system and the vehicle registration system.
• Projected cost rose to 6.5 x expected price and the delivery date was pushed back to 1998. In December 1993, the agency pulled the plug and walked away from an investment of
• seven years, and
• $44.3 million.
[Gibbs94]
American Airlines' SABRE
flight reservation system
System Success and Integration Failure
• In 1970, the $2-billion American Airlines flight reservation system, SABRE, became part of the travel industry's infrastructure and contributed to making American the largest airline in the world.
• In 1990's American tried to integrate its flight reservation technology with the Marriott and Hilton's hotel reservation systems, and Budget car rental reservation system.
• In 1992, after an $165-million investment, the failed system integration project was abandoned because of litigations.
[Gibbs94]
IBM Consulting Group 1994 Survey
• 24 leading companies that developed large distributed systems
• 55% of projects cost more than expected
• 68% of projects overran their schedules
• 88% of projects had to be substantially redesigned
• There were no figures on the reliability of the completed programs.
[Gibbs94]
Measures to Curtail Failures
• Intuition is slowly yielding to analysis as programmers begin using quantitative measurements of the quality of software
• Researchers are working on expressing program designs in algebraic forms that make it easier to avoid serious mistakes.
• Academics are starting to address their failure to produce a solid corps of software professionals.
• Industry is starting to turn its attention toward inventing the technology and market structures needed to support interchange-able, reusable software parts.
[Gibbs94]
Technology Transfer Problem
• Research innovation typically requires 18 years to be included in the repertoire of standard programming techniques.
• Industry does not uniformly apply well-known best practice.
[Gibbs94]
Software Explosion Problem
(a) Software is exploding in size as society relies on increasingly powerful computers.
(b) Most large software projects fail to meet their schedules.
(c) Many large software projects fail outright -- usually after most of the development money has been spent.

[Gibbs94]
Software Explosion
• The amount of code in most consumer products is doubling every two years.
[R. H. Bourgonjon, Philips Laboratory, Eindhoven]
- Television can contain 500Kbytes of SW
- Electric shaver -- 2Kbytes
- General Motor power trains--30K lines
List reasons why traditional software, e.g., wordprocessors and spreadsheets, are also increasing in size and complexity, instead of stabilizing
•
•
•
•
[Gibbs94]
An Brief Overview of the
SEI Capability Maturity Model (CMM)
• The Software Engineering Institute (SEI) is a software think tank at Carnegie Mellon University funded by the military
• In 1991 SEI proposed CMM to rank a programming team's ability on a 1-5 scale to create predictably software that meets its customers' needs
• Level 1 - chaos, team keeps no measu-rements of what they do and has no way of knowing when they are on track.
• Level 5 - best management
• Motorola's Bangalore India prog. team
• Loral's on-board space shuttle
[Tom Peterson, head of Loral team]
• U.S. Air Force requires its software develo-pers to reach level 3 of the CMM by 1998.
[Carnegie Mellon U., Software Engineering Inst., The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Reading, MA, 1995.]
[Gibbs94]
Raytheon's equipment division
A CMM Success Story
• In 1988 at CMM level 1, launched a "soft-ware engineering initiative" investing $1-million/year into
• rigorous inspection & testing guidelines
• training its 400 programmers to follow guidelines
• By 1991, the division ranked CMM level 3
• By 1994 most projects, including complex radar and air-traffic control systems:
• finished ahead of schedule and under budget
• productivity more than doubled
• analysis of avoided rework costs showed $7.80 saved per $1 invested initiative.
• from 1988-1994 Raytheon saved $17.2-million in software costs

[Gibbs94]
Strategies in eliminating bugs
(1 of 3)• Bugs found early in the development process rarely seriously impact the schedule or budget. The impact increases as bugs are not detected until the final stages of development.
• Some mass-market software vendors rely on a large number of volunteers to test a faulty "beta" version, e.g. Microsoft Windows. This is effective but inefficient and expensive; and impractical for software that is not for the mass-market.
[Gibbs94]
Strategies in eliminating bugs
(2 of 3)• Recognize the problem often changes as the system is being built.
• Denver airport planners made $20-million in changes to the BAE design long after construction had begun
• FAA managers were also indecisive in IBM's AAS design.
• System prototypes, like architect's scale model
• helpful in communicating expectations and requirements between customer and developers before the logical foundation is built.
• not useful in finding inconsistencies in system's design
• does not help detect bugs once a design is committed to code
[Gibbs94]
Strategies in eliminating bugs
(3 of 3)• Formal methods, theoretical tools based on set theory and predicate calculus.
• Praxis, UK, used formal methods on critical parts of Britain's Civil Aviation Authority's air traffic control project.
• smaller than FAA's AAS project but similar in requirement of synchronized redundant systems.
• found errors in design in the early stages and finished system on time. It was operational October 1993.
• GEC Alsthom in Paris wrote entire design and final program for France's $350-million upgrade to switching- and speed-control for 6,000 electric train system using B formal method and used mathematics to prove consistency
• saved billions avoiding creating new lines by increasing speed and reducing distance between of the trains.
• still used functional tests to find
• mistakes in proofs
• unexpected real world problems
[See Formal Methods: A Virtual Library. Jonathan Bowen. http://www.comlab.ox.ac.uk/archive/formal-methods.html]
[Gibbs94]
Problems with Formal Methods
• Hard to write and hard to read the mathematical formal descriptions.
• There are several research and commercial efforts to automate formal methods
• Odyssey Research Associates, Ithaca NY
• GEC and Digilog in France (B tools)
•
"I am skeptical that Americans are sufficiently disciplined to apply formal methods in any broad fashion"[David A. Fisher, National Inst. of Standards and Tech.]
• Cleanroom software engineering approach
• Mills, Harlen D., M. Dyer, and R. C. Linger, "Cleanroom Software Engineering," IEEE Software, Vol. 4, No. 5, Sept. 1987, pp. 19-24.
• mixes formal notations, correctness proofs and statistical quality control with an evolutionary approach to software development
• goal: zero defects the first time software runs
• one function programmed at a time and certify quality before integrating it into architecture
• statistically derived test cases - on most common paths
• model calculates reliability of program
• Ericsson Telecom (European's AT&T) used it on a 70-programmer project to fabricate an operating system for telephone-switching computers
• productivity ^ 70%, testing productivity ^ 200%
• errors 1/1000 LOC, industry average is 25/1000
[Gibbs94]
Productivity Improvement
• "We are not seeing any increases [in software productivity over the past two decades]"
[David A Fisher, Nat. Inst. of Standards & Tech.]
• "There has been improvement, but everyone uses different definitions of productivity."
[Richard A. DeMillo, professor at Purdue University and
head of the Software Engineering Research Consortium]
• "No one really knows how productive software developers are" [Gibbs94]:
1. less than 10% of American companies consistently measure the productivity of their programmers.
2. the industry does not have a useful standard unit of measurement [e.g. lines of code per worker per month -- meaningless if languages and complexity of operations not taken into consideration]
3. productivity variations between individual program-mers [as much as 100 x] overpowers the small effects of technology or process improvement
• Many innovations turn out to be irreproducible or unscalable. Handbooks need to be developed, similar to those in more mature engineering disciplines, that contain proven solutions so that even novices can consistently handle routine designs. [Mary Shaw of Carnegie Mellon]
• If software engineering is to be an experimental science it needs laboratories. [Victor Basili, U. of Maryland]
• Software Engineering Lab, consortium of NASA's Goddard Space Flight Center, Computer Sciences Corp. and the U. of Maryland founded in 1976
[Gibbs94]
Future: Component-Based Software?
• Develop component-based software
• Collect royalties, same as music industry
• Need to develop:
• Common language to describe software parts
• Programs that reshape components to match environment
• Components need lots of optional features a user can turn on or off
• Has been tried by
• NIST Advanced Technology Program offering $150-million in grants to help develop market
• Incremental Systems, founded by David Fisher of NIST, to make compiler components -- there was no market
• Brad Cox, pres. of Coalition for Electronic Markets, -- buyers wanted to pay for component once and copy for free, too time consuming to tailor the component for each customer.
[Gibbs94]
Future:
Everyone a programmer or certification?
• "In the future, professional people in most fields will use programming as a tools, but won't call themselves programmers or think of themselves as spending their time programming. They will think they are doing architecture, or traffic planning or film making,"
[Laszlo A. Belady, Mitsubishi Electric Research Lab.]
• With everyone programming, qualification to program life-critical, safety-critical or mission-critical systems. Certification of software engineers seems inevitable, as in other engineering fields, but certification helps only if programmers are properly trained to begin with.
[Gibbs94update]
Third World Software Exports
(1 of 2)
[Gibbs94update]
Third World Software Exports
(2 of 2)Indian Cost vs. US Cost per unit of software: $125 vs. $925
Indian SW exports compound annual growth of 38%/past 5 yrs.
In 1994 ~ 58% of $360M came to US ($360M/$92.8B market)
Prediction: software development will gradually split between Western software engineers who design systems and Eastern programmers who build them.
Companies have programming teams in 3rd world countries
India Manila (software factory)
AT&T Pact Group in Lyons, France
Hewlett-Packard Pacific Rim
IBM Cadence, US VLSI design tools
British Telecom Russia
Texas Instruments ACT, a UK-based systems house
Some companies fly an entire team to US to work on a project, 1/2 of India's software exports come from such "body shopping." US tightening visa restrictions will impact this trend.
Growing US trust in the quality of overseas project management
Time differences between India and US - round the clock work