sss ssss rrrrrrrrrr
ssss ss rrrr rrrr
sssss s rrrr rrrr
ssssss rrrr rrrr
ssssssss rrrr rrrr
ssssss rrrrrrrr
s ssssss rrrr rrrr
ss sssss rrrr rrrr
sss sssss rrrr rrrr
s sssssss rrrrr rrrrr
+===================================================+
+======= Testing Techniques Newsletter (TTN) =======+
+======= ON-LINE EDITION =======+
+======= December 1995 =======+
+===================================================+
TESTING TECHNIQUES NEWSLETTER (TTN), On-Line Edition, is E-Mailed
monthly to support the Software Research, Inc. (SR) user community and
provide information of general use to the world software testing commun-
ity.
(c) Copyright 1995 by Software Research, Inc. Permission to copy and/or
re-distribute is granted to recipients of the TTN On-Line Edition pro-
vided that the entire document/file is kept intact and this copyright
notice appears with it.
TRADEMARKS: STW, Software TestWorks, CAPBAK/X, SMARTS, EXDIFF,
CAPBAK/UNIX, Xdemo, Xvirtual, Xflight, STW/Regression, STW/Coverage,
STW/Advisor and the SR logo are trademarks or registered trademarks of
Software Research, Inc. All other systems are either trademarks or
registered trademarks of their respective companies.
========================================================================
INSIDE THIS ISSUE:
o Holiday Greetings!
o 3rd International Conference on Achieving Quality in
Software (AQuIS'96)
o THE PENTIUM BUG_AN INDUSTRY WATERSHED (Part 4 of 4)
Dr. Boris Beizer
o SOFTWARE -- A NATIONAL RESOURCE, by L. Bernstein
and C. M. Yuhas
o TTN SUBMITTAL POLICY
o TTN SUBSCRIPTION INFORMATION
========================================================================
H O L I D A Y G R E E T I N G S
All of us in the SR extended family -- employees, consultants, contrac-
tors, field agents, and international distributors -- wish to extend our
thanks to you all for our successes in 1995.
We wish you and yours the very best of the best for the 1995 Holiday
Season!
And we offer our hearty toast to good luck and great fortune for 1996!
Merry Christmas and Happy New Year!
========================================================================
Third International Conference on Achieving Quality in Software (AQuIS'96)
Florence, Congress Centre, ITALY
24-26 January 1996
Organized by:
Instituto de Elaborazione del Informazione del CNR
Consorzio Universitario in Ingegneria della Qualita
In Cooperation With: CESVIT
Sponsored by: IFIP WG5.4
Co-Sponsored by: A.I.C.A.; AICQ;
ENEA; IEEE; Universita di Firenze
With the support of: Fiat Auto
THE CONFERENCE
The objective of the AQuIS conference series is to provide a platform
for technology and knowledge transfer between academia, industry and
research institutions, in the software quality field by:
o providing a forum for the introduction and discussion of new research
results in software quality;
o providing the practicing quality engineers exposure to the results of
ongoing research;
o providing the research community exposure to the problems of practi-
cal applications.
AQuIS '96 continues in that tradition. In addition, AQuIS '96 tries for
the first time to address specifically the topic of knowledge-based sys-
tems (KBS) quality, and the impact of object-oriented technology on
quality. The development of KBS has created a strong interest in apply-
ing this technology to critical applications. There is a growing
interest in the problem of assuring KBS quality and some of the good
ideas from conventional software quality could be transferred to KBS
quality. Object oriented technology has pervaded the entire field of
software engineering, changing the way in which programs are specified
and developed. While much research has been performed on object
oriented programming, little has been said on its impact on quality.
CONFERENCE COMMITTEE
General Chair: Giacomo Bucci, U. of Florence - ITALY
General Conference Secretariat: Cristina FRANCEschi,
Consorzio Qualital,
P.zza del Pozzetto, 9,
56127 Pisa, ITALY:
Phone: +39.50.541751
FAX: +39.50.541751
E-Mail: mbxqualital@mail.cnuce.cnr.it
* * * Wednesday, 24 January 1996 * * *
Invited Paper:
"Evolving and packaging reading technologies", Prof. Victor Basili
(Dept. of Computer Science, University of Maryland, USA)
"Analysis of Fault Generation Caused by Stress During Software
Development" (T. Furuyama, NTT SW Laboratories, Tokyo, JAPAN)
Session: Process Improvement. Chairperson: Prof. MARCO MAIOCCHI
"Process Improvement through Route Cause Analysis" (F. Andreis, et.
al., Italtel Sit, Sittimo Milanese, ITALY)
"A Process Improvement Experiment through Process Modeling Technol-
ogy" (P. Coppola, et. al., Intecs Sistemi, Pisa, ITALY)
"Process Maturity-Growing Older and Wiser? Using Process Adviser for
Process Assessment" (A. Bryant, et. al., Leeds Metropolitan Univer-
sity, Leeds, UK)
Session: Quality Practices. Chairperson: Dr. MARIAN PIVKA
"Software Quality: Perceptions and Practices" (R. Barrett, et. al.,
City University, Hong Kong, CHINA)
"Controlling Side Effects in Maintenance" (G. Canfora, University of
Naples "Federico II", ITALY)
"The short but interesting life of small software firms" (R. Caponi,
et. al., University of Naples "Federico II", ITALY)
Session: Software Testing. Chairperson: Dr. EDWARD MILLER
"Static Analysis of VHDL Source Code: the SAVE project" (M. Mas-
tretti, Italtel-Sit, Settimo Milanese, ITALY, M.L. Busi, et. al.,
University of Milan, ITALY)
"Metrics and Analyses in the Test Phase of Large-Scale Software" (E.
Obara, NTT, Tokyo, JAPAN)
"Automated Testing of Safety Requirements with the Support of a
Deductive Database" (P. Asirelli, et. al., IEI-CNR, Pisa, ITALY)
* * * Thursday, 25 January 1996 * * *
Invited Paper:
"EC Projects and Efforts in the Field of Software Quality", Dr. Brice
Lepape (European Commission, DGIII F/4, BELGIUM)
Session: Numerical Assessment. Chairperson: Prof. W. D. EHRENBERGER
"Poisson Models for Subprogram Defect Analyses" (W. Evanco, The MITRE
Corp., Virginia, USA)
"Early Estimation of Software Reliablility Through Dynamic Analysis"
(A. Wesslen, et. al., Lund University, SWEDEN)
Session: Quality Measurement. Chairperson: Prof. NORMAN FENTON
"Software Quality Classification Model Based On McCabe's Complexity
Measure" (R. Takahashi, NTT, Tokyo, JAPAN)
"Combining Knowledge and Metrics to control Software Quality Factors"
(G. Alvarez, et. al., Universitat Politecnica de Cataluna, Barcelona,
SPAIN)
"Software quality education from research to industry: the Qseal Con-
sortium approach" (V. Asanghi, et. al., Qseal Consorzio, Milan,
ITALY)
Session: Quality Modeling. Chairperson: Prof. VICTOR BASILI
"In search of the Customers Quality View" (T. Stalhane, SINTEF, Nor-
way)
"Database Design for Quality" (D. Castelli, et. al., IEI-CNR, Pisa,
ITALY)
"Methodology Assistant in a Graphical Design of Real-Time Applica-
tions" (R. Aubry, et. al., INSA, Lyon, FRANCE)
Session: Object Oriented. Chairperson: Dr. FERNANDO BRITO E ABREAU
"Using object oriented technology to measure a software process" (A.
Aarsten, et. al., Politecnico di Torino, ITALY)
"Object-Oriented Software Testability" (J. M. Voas, RST, Virginia,
USA)
"Applying Metrics for Quality Analysis and Improvement of Object-
Oriented Software" (C. Ebert, ALCATEL SEL, Stuttgart, GERMANY, I. J.
Morschel, Damier Benz AG, Ulm, GERMANY)
* * * Friday, 26 January 1996 * * *
Invited Paper:
"Verification and Validation of Knowledge Based Systems", Prof. Marc
Ayel (Aderias-Lia, Universite de Savoie, FRANCE)
Session: KBS Quality. Chairperson: Mr. PEDRO MESGUER
"Software Engineering Concepts for KBS Design and Testing for Relia-
bility" (F. Battini, LABEN, Milan, ITALY)
"Assessing the Role of Formal Specifications in Verification and
Validation of Knowledge-Based Systems" (P. Meseguer, Universitat Pol-
itecnica de Cataluna, Barcelona, SPAIN, A. D. Preece, University of
Aberdeen, UK)
Session: Formal Methods. Chairperson: Dr. JEANINE SOUQUIERES
"Software Quality Improvement: Two Approaches to Formal Methods
Application" (A. Alapide, et. al., Space Software Italia, Turin,
ITALY)
"Assessing the Quality of Specification-based Testing" (S. P. Allen,
et. al., University of Liverpool, UK)
"A Tool for Testing Synchronous Software" (I. Parissis, LGI Labora-
toires de Genie Informatique, Grenoble, FRANCE)
Session: Quality Measurement. Chairperson: Prof. KAROL FRUHAUF
"A case Study in Branch Testing Automation" (A. Bertolino, IEI-CNR,
Pisa, ITALY, R. Mirandola, University of Rome, ITALY, E. Peciola,
Ericsson Telecomunicazioni, Rome, ITALY)
"A Method for Software Evaluation with respect to Quality Standards"
(H. L. Hausen, et. al., GMD, Skt. Augustin, GERMANY)
"Software Applications Complexity Evaluation in a Bank Environment"
(D. Cellino, Banksiel, Turin, ITALY)
Round Table Discussion: PROCESS IMPROVEMENT EXPERIMENT (ISO 9000, SPICE,
CMM, etc.)
o o o
Registration details for AQuIS'96 can be obtained from the conference
secretariat or from:
Consorzio Universitario in Ingegneria della Qualita
P.zza del Pozzetto, 9 56127 Pisa, ITALY
Tel. +39.50.541751 FAX +39.50.541753
========================================================================
S O F T W A R E -- A N A T I O N A L R E S O U R C E
Lawrence Bernstein & C. M. Yuhas
Presented at:
National Software Summit
Washington, DC
3 November 1995
Albert Einstein related, "Perfection of means and confusion of goals
seem, in my opinion, to characterize our age." Software is no exception.
We have an intense and important focus on software processes, but we
lack a corresponding focus on software product performance. To establish
this critical focus we must change the way we think about software. My
themes today are (1)"success is the enemy of innovation."(2) we must
begin to certify our license software professionals for safety critical
systems and (3) we need to establish software dynamics as a major area
of study and practice.
Our development approaches are usually document driven. We must move to
a risk management approach. My experience says that we need both specif-
ication and prototyping with risk assessment to be successful. Barry
Boehm's Spiral model is on target. It places formal specifications under
change control after the prototype is evaluated. Of course, such evalua-
tion is best done together with the customer. Our processes assume that
software is linear. Unfortunately we do not have the design theory to
assure such linear performance. Just as the cannons in the War of 1812
would explode randomly, software can and does crash. The cause for both
is the same. It is the lack of a solid design theory. In the case of
early 19th century cannons it was the lack understanding of metallurgy;
today it is the lack of a theory of software behavior. To be useful,
this theory needs a strong mathematical foundation. The dynamic behavior
of software will become an important field of study in the next decade
and we must continue to be at its leading edge.
Just as motors became transparent to our every day lives, so will com-
puters. Mature technologies become invisible. There will be a great
economic advantage to understanding the non-linear performance of soft-
ware sufficiently to predict its stability. This can be done in at least
two ways.
We could design constraints to bound the dynamic performance of soft-
ware, setting up mathematical models to predict its stability. Alterna-
tively, it may be possible to treat software organically. Imagine hun-
dreds of computer viruses in test labs attacking each module relent-
lessly in ways far too complex for humans to design. The surviving soft-
ware gets to live in a system. With the enormous complexity of networked
and nested systems, we surely need a scheme for design testing that is
superior to today's spot-checking. Software that works is the key to a
profitable product. When motors were first introduced into private
homes, one motor did the job for the household. Appliances were pur-
chased as add-ons to the main motor: a vacuum tool, a refrigerator tool
and so on. Because motors are reliable, you can't easily count the
number of motors that function in your life. Similarly, with reliable
software, computers can become equally invisible and ubiquitous.
Already you have your pocket calculator and your computerized car engine
in addition to your far more obvious laptop.
Rather than building general purpose computers and operating systems
that don't do anything well, the future belongs to the purveyors of spe-
cial purpose small targeted machines. The world of Ubiquitous Computing
I saw being invented at Xerox Parc points the direction. Who will bring
this invention to the marketplace and make it a profitable innovation?
The largest software company may be Microsoft. But watch Nintendo who
had sales of $5.4 billion in 1994 and $4.5 billion in 1995 and who has
the skills needed to build easy-to-use, customer focused, special pur-
pose software aimed at the next generation of industry leaders. They may
be in the best position to harness the ubiquitous computer technology
change.
Safety critical software, application generators built on object
libraries, and software fault tolerance will join ubiquitous computing
on the technology change agenda before the 21st century. We have a clear
advantage in object-oriented programming and software fault tolerance.
But the safety critical software and ubiquitous computing may be the big
opportunities for the next decade and our lead is not so clear. They
will cause a large disruption in the industry. Perhaps as large as Open
Systems did in the 80's.
Moreover, safety critical software technology cries out for trained and
skillful practitioners. Government licensing of software professionals
practicing in this software field is long overdue.
Today's software leaders will find these visions hard to swallow.
Remember early nay sayers in our industry:
"Computers in the future may weigh no more than 1.5 tons."
--Popular Mechanics, forecasting the relentless march of science,
1949
"I think there is a world market for maybe five computers."
--Thomas J. Watson, Chairman of IBM, 1943
"There is no reason anyone would want a computer in their home."
--Ken Olson, President, Chairman and Founder of Digital Equipment
Corp., 1977
"640K ought to be enough for anybody."
-- Bill Gates, 1981
"So we went to Atari and said, 'Hey, we've got this amazing thing,
even built with some of your parts, and what do you think about fund-
ing us? Or we' ll give it to you. We just want to do it. Pay our
salary, we'll come work for you.' And they said, 'No.' So then we
went to Hewlett-Packard, and they said, 'Hey, we don't need you. You
haven't got through college yet.'"
--Apple Computer Inc. founder Steve Jobs on attempts to get Atari and
H-P interested in his personal computer.
For the United States to retain its software lead we must continue to
adopt and change the technology base every 3-4 years. The rough and tum-
ble world of Yankee know-how and our institutions are geared for such
change. Our challenge is to continue to sponsor it, and to find ways
for America to capitalize on its inventions.
I am fortunate enough to be in a business that has global reach. I would
like to share a few observations about the shape of the newly emerging
world wide culture. First, it seems that English is the lingua franca of
this culture. In Brazil the language is Portuguese, but the large
English-speaking intelligentsia sees the business opportunity in setting
up an information "port," in English, on an industrial basis. The road-
block is a government that is trying to protect its communication market
by not allowing European or North American standards to be used. Freeing
the information flow would spread innovation to hospitals and education,
encouraging a regenerative cycle that would lift living standards
universally. In Taiwan, the local telephone operators all speak English.
In Japan, it is always English for technical discussion. I had the
disconcerting experience of having a business dinner in France where the
technical discussion quickly turned to English, so naturally that my
French business colleague ultimately asked the French waiter for the
bill in English. At a conference in Russia, I joined a group comprised
of German, Dutch, Russian, Czech and Polish mathematicians who had
chosen to speak to each other in English. Secondly, in The Netherlands I
was privileged to see what real practical application of technology
could mean to a society.
Ten years ago, the Dutch government made a deliberate decision to make
the most advanced technology available to each and every Dutch citizen.
This would be done by making it invisible. The most totally accepted
tools are transparent. The government invested substantial money in the
creation of a school within the University of Utrecht whose mission it
would be to develop a generation of human factors experts. These people
would combine artists' skills, computer knowledge, and psychological
research methods to design interfaces to technological tools that would
be intuitively "correct" to ordinary people. Businesses were encouraged
to use students on actual problems as part of their study, the advantage
to the business being the input of the professional teaching staff. The
teachers were all people who were prominent in fields other than teach-
ing and so knew current issues. The students, upon graduation, had
already established links to the business community. It was a real
investment in giving each person, regardless of job or educational
level, access to the modern information world. Software is a national
resource of the American economy. We continue to lead the world because
of our ability to invent and incorporate new technologies in our
approaches. We need to be keen in adapting our institutions and recog-
nizing the importance of our software industry. As we continue to invent
and innovate, we will continue to lead the world.
Barry Boehm wrote in the forward to the "Software Reliability Handbook"
the following prediction: "Sometime soon software reliability is going
to become a highly visible area and important field. Unfortunately,
given human nature, it's thrust into prominence will only happen once we
experience the software equivalent of the Chernobyl, or space shuttle
disasters. Such a disaster is likely to happen in the next few years for
the following main reasons:
1. Software is becoming central to many life-critical systems.
2. Software is created by error-prone humans.
3. Software is executed in the real world by error-intolerant machine.
4. Software development and maintenance is driven more by budget and
schedule concerns than by reliability concerns."
I'd like to close with a cautionary tale about a monkey colony on a tiny
barren island off the coast of Japan. They were experiencing an extraor-
dinarily severe winter and the Japanese government, in a humanitarian
effort to save the colony from starvation, arranged to have some grain
spread on the sandy beach. The hungry monkeys tried to pick up the
grain, but got inedible mouthfuls of sand along with it. In rage and
frustration, a young juvenile threw a handful into the water. The sand
sank and the grain floated, making it easy to gather and eat. Soon every
young monkey was imitating that first proto-engineer. The females fol-
lowed their babies into the sea and learned the technique in the pro-
cess. The colony survived that winter. Only the old males, afraid of
change and reluctant to abandon their formerly successful ways, starved
to death in the cold. The lesson is, "Success is the enemy of innova-
tion."
REFERENCES
[Bern89] Bernstein, Lawrence and Yuhas, Christine M. "How Technology
Shapes Network Management," IEEE Network Magazine, July 1989, pp. 16-19.
[Gomo95] Gomory, Ralph E. "National Productivity and Computers," Com-
puter, July 1995, Vol. 28, No. 7, pp. 66-72.
[Kell94] Kelly, Kevin. Out of Control: The New Biology of Machines,
Social Systems and the Economic World, Addison-Wesley Publishing Com-
pany, New York, 1994.
[Lewi95] Lewis, Ted. "Living in Real Time, Side A," Computer, September
1995, pp. 8-10.
[Pars83] Parsons, Gregory L. "Information Technology: A New Competitive
Weapon," Sloan Management Review, Vol. 25,No. 1, Fall 1983, pp. 3-13.
o o o
EDITORS NOTE: Lawrence Bernstein is Operations Systems Vice President at
AT&T Network Systems (email: lbernstein@attamil.com) and C. M. Yuhas is
a freelance writer.
========================================================================
THE PENTIUM BUG_AN INDUSTRY WATERSHED (Part 4 of 4)
Dr. Boris Beizer
------------------------------------------------------------------------
Copyright, Boris Beizer, 1995. Permission is granted to print this docu-
ment for personal use and to redistribute it for internal corporate use
subject to the provision that this entire copyright notice must appear.
Use of this document or parts thereof in any commercial publication or
document without the written permission of the author is strictly prohi-
bited.
------------------------------------------------------------------------
1. General
Two guys in the Australian Outback, a dozen polar Eskimos, and a tribe
in the Amazon jungle have not heard about the Pentium bug. People
oblivious to floating point arithmetic before INTEL's customer relations
fiasco now speak angrily about this bug and how it will affect their
lives. There are a half-dozen class action suits afoot claiming warran-
tee breaches and false advertising, as well as a few stockholders' suits
[INTE95]. This bug has probably been blamed for every human and techni-
cal misery from anorexia to zygopteran infestations.
Was this bug serious? Yes and no. Technically, it wasn't the first, it
wasn't the worst, and it won't be the last of its kind. But from the
point of view of its impact on the computer industry, it is probably the
most significant bug ever. It has forever transformed the industry. It
is a watershed for all of us.
Some of you who are in software might mistakenly believe that this was a
hardware bug and that it therefore doesn't affect you: if so, you're
wrong on both counts. It was a software bug, but one that happened to
be compiled into silicon rather than RAM. But it doesn't matter if it
was hardware or software because the users, as we have just learned, do
not make that distinction.
<>
4.5. Educate Users
Our consumers need education in statistical thinking. It's a pity that
the average American manager knows less statistics than the average
Japanese production worker. More sophisticated statistical thinking by
consumers wouldn't just benefit the computer and software industry, but
all industries. Yes, we should do what we can to educate the user to
have more realistic expectations, but I have no great hope that it will
do any good in the short run or even in the long run. As my brother
[BEIZ95], who is an art historian but a savvy computer consumer, put it:
"Consumers don't want to be a statistic!"
4.6. Crisis Management Exercises
I called several companies in researching this piece. I made a point of
not calling any of my many technical contacts because I knew that they
would not be authorized to speak for their company on policy matters.
In call after call, well intentioned people tried to steer me to a
representative in technical support, design, or Quality Assurance. In
other words, to people like you and me. Sorry guys we're not trained
for the job. We're not trained to seem to provide open, honest, com-
plete, disclosures while actually saying nothing. We're not trained to
spot the legal mine fields that lead to stockholders' class action
suits. And we're certainly not trained to deal with professional report-
ers who have the skill to draw you into making statements (albeit
correct ones) that you and your organization might later regret.
Organizations that contend with consumers and deal with the possibility
of bugs in their product must train themselves to effective response.
One way to do that is to run crisis simulations. You get outsiders
including retired reporters, PR professionals, financial analysts,
stockbrokers and technical experts to do role playing with executives,
from the CEO down to QA and development managers and a sample of your
designers, tech support, customer service, QA and telephone operators.
You have to include workers in the simulation because one way or
another, if there's a story, the press and the public will try to get to
them and how they respond may shape the subsequent evolution of the
simulated crisis. Do it on a private BBS by Email. Do it at least once
for every release. Hypothesize a killer bug and see how the company
responds. Then do a retrospective and see if you goofed or played it
right. Make sure to have a reality check by having a professional PR
firm judge and critique the result. Such simulations aren't cheap in the
short run: you have to pay the outsiders and you have to divert valuable
insider time to the task. It costs money to do the retrospective
analysis. The payoff is in the long term.
4.7. Stop the Model Year Mentality
For about 50 years, from 1930 to 1980, the American automobile industry
enslaved itself to the new model year. In an attempt to boost sales by
fostering obsolescence and premature replacement, the auto industry made
a big thing out of the new model every year. In reality, most of the
annual changes were cosmetic and superficial. Key components such as
power trains and suspensions changed slowly. But that didn't mitigate
the perception that getting the latest model was the most desirable
thing. The American auto industry learned its lesson the hard way, by
losing huge chunks of market share. Today, while there's still some of
the hoopla of new models, it is far more subdued and far less important
in the consumers' minds than it once was. Corrective and enhancing
changes occur continually throughout the year. While entirely new cars
may come out, they're not associated with any specific year. It used to
be: "Get the 1995 Belchfire 400", but now it's "A totally new car! The
Belchfire 400" with no particular model year in evidence.
We have a model year mentality in our industry-- for both hardware and
software: the annual COMDEX circus is a good indicator of that. Such
shows create expectations of radically new features in each new model.
The model year mentality destroys quality because testing and quality
assurance is sacrificed to meet that all-important COMDEX deadline.
Play it down, folks-- let's kill the model year once and for all. Let's
number releases uniformly with an arbitrary, industry-wide convention
such as ., where is the number of years
since ENIAC went live, say. So packages this year are called release
49.1, 49.2, etc. Bug fixes are included, of course, but so are incre-
mental improvements throughout the year. When I replace my cars, it's
not because they don't work: it's because the incremental improvements
have accumulated to the point where I'll pay for the features I don't
have on my old car. Sure you let the public know what's new and
improved, but it's not keyed to an all-or-nothing model year. Then,
just as consumers expect bug fixes along with incremental improvements
in their new cars, they may learn to accept the same for software and
computers.
4.8. The Problem is Parts
I owe this insight to my brother [BEIZ95]: "The problem," he said, "is
parts." I didn't understand what that meant, so I asked him to
explain.
"We [the consumer] don't care and don't want to know about `parts'.
The Pentium is just a part. We don't care where the power supply
comes from, or the case, or the memory, just as long as they work.
Who cares if the brakes on our car are made by Bendix or Bosch, or
whoever: do they work? And if they don't work, how do I get it
fixed?"
That's the point. The processor chip is just a part, as is every soft-
ware package. Consumers don't know, don't care, and don't want to know
about parts-- just about the entire system, hardware and software.
INTEL created its own problem with those "INTEL inside" advertisements.
They created a "parts" awareness. Now when the part is seen to be
faulty, who can blame the consumer for wanting a free replacement part.
If parts awareness ("INTEL inside") had not been so high, then the soft-
ware fix for spreadsheets, such as the Lotus fix, would have been fine
for most consumers because most don't use big spreadsheets, most don't
need more than a few significant digits, and most can tolerate the mod-
est performance degradation of the software fix. And most important of
all, as I'm sure events will prove, most won't want to take on the
expense and risk of replacing the processor chip even if the new chip
itself is free. Without "INTEL inside" awareness, most consumers would
have gone to their system vendor, (be it Compaq, Dell, HP, IBM, or
Packard Bell) and asked "Does it matter and if it does, will you fix
it?"
Why did INTEL push parts awareness? I don't speak for INTEL of course,
but it seems to me that concern over competition such as Advanced Micro
Devices must have had something to do with it. Did INTEL calibrate its
assumption that the "INTEL inside" campaign would help it increase or
maintain market share? Did they take into account the risks of creating
parts awareness?
I know I don't like it and you probably don't like it, but computers and
their software have become a consumer product. Increasingly, it will be
consumer perceptions and wants that drive this industry. Increasingly,
the "parts", hardware or software, will be further and further away from
the consumers' minds and concerns. Increasingly, they will purchase (or
more likely, lease) a total hardware/software package from a single ven-
dor, be that a computer company, a software company, a cable company, an
entertainment company, a communications company, or some as yet unreal-
ized agglomeration of all of the above. Those are the entities that
will have to deal with consumer perceptions. Their technical experts
will speak to our technical experts and in those interchanges, we will
be able to talk about bits, bytes, MTBF, and bugs/KLOC's. We, the
technical community, will probably never learn to talk to consumers.
And because of that, we need the insulating layer of organizations and
people that can.
The Pentium bug is a watershed because it focuses on and accelerates the
ongoing fundamental transformation of the computer hardware/software
industry into the consumer domain. It is a watershed because it exposed
the fundamental misconceptions we had about what users think and believe
about bugs and how we should and shouldn't react to those beliefs.
5. References
ATKI68 Atkins, Daniel E. Higher Radix Division Using Estimates
of the Divisor and Partial Remainder. IEEE Transactions
on Computers, Vol. C-17, #10, Oct. 1968, pps. 925-934.
BEIZ90 Boris Beizer, Software Testing Techniques, 2nd Edition,
Van Nostrand Reinhold, 1990.
BEIZ95 Samuel Beizer. Private communication.
IBMS95 Pentium Study, IBM Research White Paper, December 12,
1994.
INTE95 Interview of Howard High, INTEL, February 2, 1995.
LOTU95 Interview of Peter Cohen, Lotus Development, February 2,
1995.
NADL56 Nadler, Morton. A High Speed Electronic Arithmetic Unit
for Automatic Computing Machines, Acta Tech (Prague), #6,
1956, pp. 464-478.
SASS95 McGrath, Sue. Private Correspondence, SAS Institute,
February 9, 1995.
SHAR94 Sharangpani, H.P., and Barton, M.L., Statistical Analysis
of Floating Point Flaw in the Pentium Processor. INTEL
Corporation white paper, November 30, 1994.
------------------------------------------------------------------------
Boris Beizer, PhD
ANALYSIS
1232 Glenbrook Road
Huntingdon Valley, PA 19006
PHONE: 215-572-5580
FAX : 215-886-0144
Email: BBEIZER@MCIMAIL.COM
------------------------------------------------------------------------
Editor's Note: Our heartfelt thanks to Dr. Beizer for his contribution
to the TTN/Online! If you missed any of the previous three installments
of this article, Email us at "ttn@soft.com", and request "Beizer back-
issues".
========================================================================
------------>>> TTN SUBMITTAL POLICY <<<------------
========================================================================
The TTN On-Line Edition is forwarded on the 15th of each month to sub-
scribers via InterNet. To have your event listed in an upcoming issue,
please e-mail a description of your event or Call for Papers or Partici-
pation to "ttn@soft.com". The TTN On-Line submittal policy is as fol-
lows:
o Submission deadlines indicated in "Calls for Papers" should provide
at least a 1-month lead time from the TTN On-Line issue date. For
example, submission deadlines for "Calls for Papers" in the January
issue of TTN On-Line would be for February and beyond.
o Length of submitted items should not exceed 68 lines (one page).
o Publication of submitted items is determined by Software Research,
Inc., and may be edited as necessary.
========================================================================
----------------->>> TTN SUBSCRIPTION INFORMATION <<<-----------------
------------------->>>NEW INSTRUCTIONS!!<<<-------------------
========================================================================
To request a FREE subscription or submit articles, please send E-mail to
"ttn@soft.com".
TO SUBSCRIBE: please use the keywords "Request-TTN" or "subscribe" **AND
INCLUDE YOUR EMAIL ADDRESS** in the Subject line of your E-mail header.
To have your name added to the subscription list for the biannual hard-
copy version of the TTN -- which contains additional information beyond
the monthly electronic version -- include your name, company, and postal
address in the body of the mail message.
TO CANCEL: include the phrase "unsubscribe" or "UNrequest-TTN" **AND
YOUR EMAIL ADDRESS** in the Subject line.
Note: To order back copies of the TTN On-Line (August 1993 onward),
please use the keywords "Back issue request" in the Subject line, and
please specify the month(s) and year(s) in the body of your message when
E-mailing requests to "ttn@soft.com".
TESTING TECHNIQUES NEWSLETTER
Software Research, Inc.
901 Minnesota Street
San Francisco, CA 94107 USA
Phone: (415) 550-3020
Toll Free: (800) 942-SOFT
FAX: (415) 550-3030
E-mail: ttn@soft.com