sss ssss rrrrrrrrrrr
ssss ss rrrr rrrr
sssss s rrrr rrrr
ssssss rrrr rrrr
ssssssss rrrr rrrr
ssssss rrrrrrrrr
s ssssss rrrr rrrr
ss sssss rrrr rrrr
sss sssss rrrr rrrr
s sssssss rrrrr rrrrr
+===================================================+
+======= Quality Techniques Newsletter =======+
+======= November 2003 =======+
+===================================================+
QUALITY TECHNIQUES NEWSLETTER (QTN) is E-mailed monthly to
subscribers worldwide to support the Software Research, Inc. (SR),
eValid, and TestWorks user communities and to other interested
parties to provide information of general use to the worldwide
internet and software quality and testing community.
Permission to copy and/or re-distribute is granted, and secondary
circulation is encouraged by recipients of QTN, provided that the
entire document/file is kept intact and this complete copyright
notice appears in all copies. Information on how to subscribe or
unsubscribe is at the end of this issue. (c) Copyright 2003 by
Software Research, Inc.
========================================================================
Contents of This Issue
o FT-150 WebSite Comparisons
o On Being Competitive, by Boris Beizer
o SQRL Report: Formal Verification of Timed Transition Models
o Conference on E-Commerce Technology (CDC'04)
o eValid: A Quick Summary
o First International Workshop on Mobile Commerce and Services
(WMCS)
o QTN Article Submittal, Subscription Information
========================================================================
FT-150 WebSite Comparisons
<http://www.e-valid.com>
Introduction
Does WebSite quality track with company size and reputation? How
well do big companies WebSites rank? Can we learn something by
studying the technical properties of these big WebSites? By
comparing them, one against another? We did this -- using data
collected from the FT-150 (see below). We think you'll find the
results illuminating!
The compete report FT-150 is found at this URL:
<http://www.soft.com/eValid/Customers/England/FT/Summary/ft150.basic.html>
Methodology
We aimed to compare a set of WebSites for their technical quality as
measured from typical user's perspective. To accomplish this we
applied a set of tests of mechanical and technical features of each
WebSite that investigate two important WebSite quality attributes:
the ease of user navigation, and the quality of WebSite maintenance.
Here's how these are defined:
Ease of User Navigation [Qn]. This factor is a combination of the
average rate of download of pages, the depth of the pages within the
WebSite, and the number of successful page downloads. A high score
on ease of navigation means that users will be likely to have quick
responses as they work on the WebSite, and that as they work they
will find very few broken or unavailable pages.
Quality of WebSite Maintenance [Qm]. This factor is based on the
relative age of pages found on the WebSite combined in part with the
number of pages that are broken or unavailable. A well-maintained
WebSite has very-current information (young pages), and very
reliable information (no unreachable pages). Combined, a quality
score on these factors indicates that great care has been taken to
assure the quality of the information.
Crunching The Numbers
We used the eValid WebSite analysis engine, programmed as described
below, to collect specific metrics that contribute to these factors.
We put the data into a spreadsheet and massaged the data in a number
of ways. For simplicity all the data values were converted to
normalized relative values. After computing the scores for the two
dimensions [0%-100%, with 100% being the best possible score for
that factor] we multipled the two values Qn and Qm to arrive at the
Total Quality Score = Qn * Qm, the value used to find the Quality
Rank.
Results
Here's what we found out!
o Size Ranking. First, we computed the Quality Rank for all 150 of
our candidate WebSites and showed these values in the table
along with the measured percentage of broken/unavailable links
(page return code 400 or greater), percentage of old pages
(dated more than 2 days ago), and percentage of slow-loading
pages (more than 2,000 msecs download time on a fast DSL). See
the Corporate Size Rank FT-150 Results Chart. The top 12 entries
of this table are shown below.
---------------------------------------------------------------
Top
150 Percent Percent Percent Quality
Rank Company Broken Old Slow Rank
---------------------------------------------------------------
1 WAL-MART STORES 0.00% 13.73% 0.09% 44
2 GENERAL MOTORS 43.00% 0.03% 0.08% 117
3 EXXON MOBIL 10.00% 0.06% 1.26% 25
4 FORD MOTOR 75.00% 3.97% 0.39% 147
5 GENERAL ELECTRIC 0.00% 36.22% 1.00% 103
6 CITIGROUP 0.00% 5.59% 0.19% 11
7 CHEVRONTEXACO 0.00% 8.21% 0.22% 20
8 IBM 23.00% 5.66% 0.28% 87
9 AMERICAN INTERNATIONAL 1.00% 10.84% 0.19% 32
10 VERIZON 47.00% 23.78% 0.12% 146
11 ALTRIA GROUP 0.00% 5.80% 6.70% 31
12 CONOCOPHILLIPS 1.00% 10.30% 0.00% 26
---------------------------------------------------------------
o Quality Ranking. Next, we sorted the same data table in
decreasing Quality Rank order. See the WebSite Quality Rank FT-
150 Results Chart. The top 12 entries of this table are shown
below.
---------------------------------------------------------------
Top
150 Percent Percent Percent Quality
Rank Company Broken Old Slow Rank
---------------------------------------------------------------
118 DUKE ENERGY 0.00% 1.60% 0.10% 1
113 NORTHWESTERN MUTUAL 0.00% 0.40% 1.40% 2
38 METLIFE 1.00% 0.60% 0.70% 3
65 NEW YORK LIFE 2.00% 0.60% 0.02% 4
19 CARDINAL HEALTH 2.00% 1.60% 0.00% 5
26 J.P. MORGAN CHASE 0.00% 3.67% 0.41% 6
84 MASS. MUTUAL 0.00% 4.19% 0.13% 7
93 AUTONATION 0.00% 4.35% 0.82% 8
110 3M 0.00% 4.55% 0.65% 9
62 PEPSICO 1.00% 1.60% 3.00% 10
6 CITIGROUP 0.00% 5.59% 0.19% 11
76 INGRAM MICRO 0.00% 0.00% 6.00% 12
---------------------------------------------------------------
Observations and Comments
There are many aspects of this data that are surprising and unusual.
Here are some of our observations:
o WebSite Quality IS Not Correlated With Company Size. Clearly,
WebSite quality is not apparently connected with company size.
o The Biggest Companies Have The Biggest Problems. Some of the
largest companies rank worst in terms of WebSite quality. Only
one of the top dozen firms in terms of WebSite quality, was in
the top dozen largest companies. Perhaps of more concern is the
fact that, of the top dozen WebSites by company size, four
actually rank in the lowest third of the WebSite quality
ranking. Worse yet, two of the top 12 are very near the bottom
of the list!
o The Highest Quality Companies Are Not Known for IT Excellence.
Only two of the top 12 quality WebSites are from companies which
you would think of as in the "IT sector". It's interesting that
of the top dozen quality ranked companies, four are insurance
companies, and two are banks. Is there a message here?
o There Were Some Big Surprises. There were lots of surprises in
the way the numbers turned out: AT&T ranked 148/150 and Cisco
Systems ranked 123/150. Hewlett-Packard and Microsoft were
nearly tied 91/150 and 92/150 -- close to the bottom of the
middle third. IBM at 87/150 and Intel at 63/150 were also
unexpectedly low scores. About Our Measurements We began our
work in August 2003 when the UK's Financial Times newspaper
asked BlueRiverStone and eValid to survey and compare the
WebSites of the top 150 of Fortune Magazine's Fortune 500
Companies. That survey involved both technical comparisons [this
report] and other assessments [to be published].
To assure comparability of the technical analysis data, all the
eValid site analysis runs were made serially during normal working
hours on the same Windows 2000/Professional machine using a
dedicated 386 Kbps DSL.
The 150+ eValid runs were all limited (using eValid's site analysis
setup and control menus) to analyze only the first 1000 pages out to
depth 3 from the top page on the site. If you'd like to look at the
full set of eValid preferences used, the blocked URL file use, and
the complete set of raw data used in the above survey please let us
know.
========================================================================
On Being Competitive
by
Boris Beizer
Note: This article is taken from a collection of Dr.
Boris Beizer's essays "Software Quality Reflections" and
is reprinted with permission of the author. We plan to
include additional items from this collection in future
months.
Copies of "Software Quality Reflections," "Software
Testing Techniques (2nd Edition)," and "Software System
Testing and Quality Assurance," can be purchased
directly from the author by contacting him at
<bbeizer@sprintmail.com>.
1. Perspective
1.1. Surfing on The Internet
Harassed by colleagues over my continued use of snail-mail, I
finally got Email service in 1993. That may seem to be a long time
ago and that the frustrations I went through would not occur today.
But we professionals tend to forget such problems once we have
mastered them; and, more important, we forget that our users
continue to face the equivalent problems whenever we present them
with a new or substantially upgraded product.
What had seemed like an acceptable $35/year and easy installation
escalated. Working at 2400 baud, I learned, was no more acceptable
than Morse code; so the modem had to be upgraded. The new board was
the latest with smart compression and speeds to 56 kilobaud. A
couple of test runs with the modem vendor provided trouble-free
operation at an incredible 54 KBD. Wow! But tell that to my
applications, my com package, and my Email vendor! Six packages had
to be upgraded: which was especially frustrating because I couldn't
download the upgrades at better than 2400 baud until they had been
installed, naturally. Then I had to research new modem control
sequences and telephone numbers for almost everyone I contacted.
A few weeks of fiddling around and everybody could talk at 2400 baud
again. The Email sort of works at 9600 baud. I say "sort of"
because when I tried to upload files there were so many
retransmissions that the effective rate was only 300 baud. And I
was looking forward to real-time video on the information highway --
dream on.
That wasn't the whole cost -- just the beginning. Four books and
directories: $124 and 50 hours of reading. Learn new jargon with new
buzzwords. All kinds of neat services on the information highway
that I can't get. Those I can, have connection charges that rival
the fuel consumption cost of the shuttle.
What did I gain with the new technology? Instead of justified text
in the type font of my choice, I'm back to 10 point Courier, a hard
carriage return every 70 characters, and a text editor more
primitive than EDLIN. I have a new chore now: check my Email
several times a day. And people don't answer their Email with
greater alacrity than they answer faxes or snail mail. Instead of
piling up on their desk, it piles up in their inbox.
My first tries at Email were pathetic. It took a dozen shots to get
the first message through. An attempted mailing list was worse: all
50 recipients were rejected. Transmitting this essay also failed.
The electronic superhighway is missing entry ramps and it has
potholes big enough to swallow a trailer full of Pentiums. It's
aptly called Internet surfing. Based on my own unsuccessful attempt
to learn wind surfing, it's about as difficult and equally
undignified -- you spend a lot of time floundering around, half
drowned, in the water.
1.2. For What are We Competing?
The above confession seems to have little to do with software
quality and competitiveness. But the experience is germane. Think
of the time and the frustration it takes us professionals to learn
new software and then think of our users, most of whom can't
tolerate this special kind of self-inflicted abuse. We should all
go through the experience of learning new software at least once a
year to keep a perspective on what our users go through and what
quality is really all about.
For what are we competing? If you write shrink-wrapped software,
you're directly competing for market share. If you work on embedded
software, your product is competing against alternatives. If your
software is internal, you're competing against outsourcing. Those
are the superficial aspects of competition as are "Japan," "the
EEU," "Indian programmers," "job-shoppers," and even "Microsoft."
Our notion of competition should be deeper. If you think of
"competition" as just beating your rival in the marketplace (be that
rival the software company across the river or the country across
the ocean), then you'll lose. You'll lose because such a narrow
view of competition leads to a struggle for short-term advantages, a
premature rush to market, software overloaded with marginally useful
gizmos, disdain for the user, and a fascination with technology for
the sake of technology rather than utility. So, for what should we
compete? Permanence and love.
1.3. Permanence
Permanence. Look into yourself and recognize that you, as most
engineers before you, have an edifice complex. We want our
creations to outlive us: be they pyramids, roads, cathedrals, or
word processors. I've built lots of software over the years, but
which do I remember? The software that's still running thirty years
later. Every line of that software's been rewritten and rehosted a
dozen times, but the essential vestige of my contribution remains,
and that's what made the effort worthwhile. Think of the
justifiably proud Roman road builder who, having traveled forward
through time, looks now at Italy's Autostrada. If any of his stones
remain in the roadbed, they're buried beneath tons of concrete; but
he recognizes the topography and says, "I surveyed that route: it
was the right route then and they're still using it today."
But the software engineer's permanence is unlike the permanence of
our engineering predecessors. The world's greatest assembler is an
anachronistic curiosity today. Our permanence isn't the static
permanence of stone and steel. It's the subtler permanence of
continually evolving DNA. It is the permanence of change.
Permanence is achieved through adaptability to an ever-evolving
computational environment: to migrate from mainframe, to PC, to
network, to cyberspace, and even to hyperspace when that time comes.
1.4. Love
I love the Brooklyn bridge. A hundred years later it is still doing
its job. It is as beautiful as when the Roeblings, father, and son
and wife, built it. I love it because it works. Conceived in the
days of horse-drawn wagons and steam railroads, it still works for
rapid transit cars and 18 wheelers. I love it and so does any
feeling person who sees it. I've battled my way through downtown
Manhattan, and worse, downtown Brooklyn traffic just for the thrill
of going over it.
I have a very few software packages that I love. And I don't mean
'like,' I mean 'love!' I love their honesty, robustness,
forgiveness, and most of all, their anxiety-free use. These
programs are loaded at startup and always appear as icons in the
lower-right corner of my screen. They're so much a part of my
computing lifestyle that it's unthinkable not to have them. The
vendors get my $59.95 every year. If they told me tomorrow that the
package would no longer be sold, but had to be leased annually, I
would just ask: "Where do I sign?"
We build utilitarian products, not merely beautiful and permanent
products. Who needs a great bridge that leads to nowhere? What use
is a permanent fiasco like the Aswan dam, that's all but destroyed
Egypt's agriculture? We crave our users' love. Wouldn't it be a
kick to read your Email one morning and learn that your subroutine
had been called 107 million times?
Our fickle users' love is hard-won and easily lost. Raw utility
isn't enough to earn and keep their love, especially if that utility
is bought at a cost of increased anxiety. Bells, whistles, and
functionality gizmos will dazzle them for a while, but with whom do
you want to live out your retirement years? Most people prefer
reliability, health, intelligence, and predictability over fleeting
physical beauty and dazzle in their spouses. And even passionate
love, if continually irritated by disfunction, can turn to equally
passionate hatred.
2. Who's Competing?
2.1. Concentric Competition
We compete in three concentric circles. In the outermost circle, as
a community of software developers and testers. Within that, as
software producing organizations. And finally and most important,
as individuals within organizations that are within a community.
2.2. As A Community
The community is not your city, state or country. Our community is
a world community of software developers, testers, and quality
assurance workers. Against what, does this our community, compete?
The flip-side of "competition" is the possibility of displacement.
Can we conceive of a world without software? To compete as a
community means that software itself must achieve permanence by
earning the users' love. I'll grant you that we've got their
attention, but how about their love?
I'm not complacent about the permanence of software. The world could
exist without software as we know it. No technology is permanent.
And new technologies, such as software, are most vulnerable.
Technological displacement is not always that of an older technology
by a better: stone by copper, copper by bronze, bronze by iron, iron
by steel, and steel by carbon-epoxy. History has many examples of
societies that rejected new technology or even reverted to an older
one they had discarded in order to achieve the kind of life that
they sought. Imperial China is a good example; they blocked
external technology for centuries. The Romans had factories and
mass production that gave way to Medieval guilds and piece work.
Religious groups avoid technology out of conviction all over the
world today and have throughout history. And California,
especially, has many groups that choose a non-technological
lifestyle.
"hhat choice do they have?" you might ask. That's a rotten basis
for a relation: besides, they do have choices. If the human costs
of the technological loose-cannon aren't relieved, society will live
without it. If the ills of abusive software aren't cured, society
will learn to live without that too. Here are some possible societal
alternatives:
1. Curtail Innovation. Suppose, that in reaction to persistent
and debilitating Y2K problems our users forced an innovation
moratorium onto us out of desperation. The software development
that remained could be done with far less labor than today. What? A
world without innovation? Without software innovation?
Unthinkable! Neither unthinkable nor unprecedented. Innovation
satisfies mostly the innovators. "Innovation is fundamental" is a
Western myth, especially an American myth, of recent origin. Through
history, most societies have gotten along with very little
innovation.
2. Hardware Implementation. Compiled hardware is an obvious
alternative. Spend more on initial development, freeze the
functionality, restrict evolution, and sell the chips. Sure cuts
into the job market for programmers doesn't it?
3. Dump Technology. Many science fiction stories explore non-
technological futures without computers and software. Dune, by Hal
Clemens, is one of the most chilling such exploration for us: all
computation is replaced by human "Mentats" and computers and
software as we know them, are outlawed on penalty of death.
As a community, we have a very messy act. When we don't kill some
of our users outright, we do it more slowly through frustration. If
we don't clean up our act, they will. At the most benign, they, the
users and their voice, the politicians, will force ill-conceived
rules and standards on our work. At the most extreme, they'll do
away with software altogether.
Our first goal must be to achieve permanence as a community of
developers, testers, and QA workers: to maintain our competitiveness
against the non-software and non-technological alternatives.
2.3. As Organizations
Organizational competition is what people usually mean by
"competition." Most notions of organizational competition are a
brand of naive social Darwinism: survival of the fittest and all
that. It's flimsy science to apply the methods and theories of one
domain to another by analogy. Just because quarks are the
fundamental particles of physics, doesn't mean that "organizational
quarks" is a productive idea. It sounds silly when I do it with
physics; it's as silly to argue by analogy from biology to
engineering. Survival of the organizationally fittest? It doesn't
even work that way in nature. Luck has as much to do with which
species survives as does fitness. Humans are distinguished from
beasts in their ability to make their own luck -- evil or good.
The sports model is another mythological notion of competition.
Competition is seen as a game played on a level playing field
against a matched opponent. It isn't a game. The playing field was
never level, and as time passes, the field gets hillier.
"Competition" means that the user has alternatives. The likeliest
alternative isn't software that does the same thing, but doing
without. The users' second alternative is a different way of doing
the job, not your competitors' product. The least viable
alternative is your competitors' product. If your organizational
notion of competition is to "out-Microsoft Microsoft," you've
already lost because the user will take one of the two other
alternatives first.
1. Doing Without. MS-DOS and COBOL aren't dead. While some users
may stick with unstylish technologies out of fear, many do it after
rationally evaluating their needs and what it costs to meet those
needs. The biggest competitor is not -- Sam's product is better than
yours -- but "Who needs it?" What happened to: flying
automobiles? personal helicopter? amphibious cars? dedicated
egg-fryers? Look at the reruns of Popular Science News films from
the '30's and '40's to see how many "indispensable" gadgets we've
learned to do without.
2. Doing it Differently. If the software's function is essential,
there may be another way of doing it. That's the second rank of
competition. What happened to Western Union? Do you remember
Telex? Acoustic couplers? TeleAutograph? Morse code? Semaphore
towers? The pony express? Steam engines? Clipper ships?
The clipper ship is an example of doing it differently. For all the
hoopla, the clipper ship era barely lasted two decades. It was a
search for speed under sail at the expense of all other user needs.
They were very fast: they made records that weren't bettered for a
hundred years. And recreational sailors today still try to beat the
records of those great romantic beasts. But they had crews twice as
big as saner ships and they wore that crew out at twice the normal
rate. And they were delicate. Most didn't make more than a few
voyages. Toward the end, they sacrificed cargo (and passengers, it
is told) overboard for greater speed because the money was made
betting on the race and not on shipping cargo. The users, the
people who wanted to ship goods to and from California, told the
shippers off most eloquently. They chose slower, safer means of
transport. Eventually, they selected steamships: an even slower, but
even safer and less labor-intensive, technology.
Within our industry, we have examples of how software of one kind
was displaced by a different kind rather than by a competing product
of the same kind: special financial computation programs by
spreadsheets, assemblers by optimizing compilers, message switches
by Email, mainframes by networks.
3. Going to a Competitor. A competitor is the users' last, and
least viable, choice. They can't do without it and they haven't yet
recognized an acceptable displacement alternative. Because they're
unsatisfied with your product, you'll lose to a direct competitor.
Actually, that's the most rational and easiest competition there is.
It doesn't take industrial espionage or rocket science to learn all
you need to know about your direct competitor's product and to
combat that product in the marketplace.
You should do that, of course, but there are a few things you
should first confirm.
a. Is it Your Competitor? Often, organization X focuses on
seeming competitor Y for non-rational reasons. Competitive
perception may be based on such things as: they are former employees
or associates (very common), a single bad experience in the past, a
fratricidal lawsuit. Get an independent reality check on market
share. Your biggest competitor has the biggest market share.
Period. Your perceived worst competitor could really be your best
ally: and in these days of consolidation, that's especially
important. Make sure, before you squander your energy or forego
strategic alliances, that your efforts are focused on your real
competitor rather than your emotional competitor.
b. Users hate to change. It's likelier to be something bad that
you're doing that drives your user to a direct competitor than
something great the competitor is offering that attracts them away
from you. You've probably disappointed your users not once, but
often. The competitor just happened to be around to cash-in on the
rebound. If you don't face your own negatives, you'll never hold
your users.
c. Even Playing Field? It's only when the product is totally new
that the playing field is even. That will become rarer in the
future as the market becomes saturated. Our industry has matured.
With maturity comes concentration and the wholesale elimination of
smaller competitors. The playing field, when it is level at all, is
only level for major league players. You're unlikely to win at their
game: you have to change the game.
2.4. As Individuals.
The toughest competition is at the individual level. But, to
compensate for that, it's also the competition over which you have
the most control. As individuals, you have three competitors. Of
these, the least obvious and most difficult is yourself.
1. The Other Guy. "The Other Guy" is most frequently seen as the
individual competition: that other programmer or tester who's better
trained, luckier, more politically attuned, etc. Sometimes it is
that way, but usually not. Here again, the mythological sports
model does us in. Another, perhaps closer myth is the entertainment
industry and talent competitions. Software development is a
cooperative process. You have to marshal the efforts of tens or
hundreds to achieve desired goals. Right-thinking managers look for
competent cooperators rather than individualistic superstars. I
don't worry about the super-talented software superstars. They're
statistically insignificant and you rarely meet them head-on. When
I examine the jobs I didn't get over the years, it was usually
because of a mismatch between what I offered and their perceived
needs. Only a few times can I honestly say that I lost to "The Other
Guy." And only once, rightfully, to a superstar. Don't worry about
the other guy! She's not your competitor. Looking over your
shoulder at a supposed competitor detracts from your ability to do
competent cooperative engineering. It deflects you from the need
for self-improvement. Taken to extremes, it's paranoid.
2. The Younger Guy. We all get older. As the industry matures,
the mean age of its participants increases. Short-sighted bosses,
violating law and rationality, lay off older workers to hire younger
ones. The motivation is obvious: entry-level salaries and fringe
benefit costs are lower: an attractive, if misbegotten, inducement
to employee turnover. The rationalization most often given for such
action is that "the recent graduate is more up on the latest stuff."
It's easy to put the lie to that one, as you'll see below.
The younger worker does have an advantage: ignorance. He doesn't
know what doesn't work, so he tries anyhow.
If you're closed to new ideas, that's your doing, not the younger
guys". As professionals, we have a duty to be mentors to our new
colleagues. To impart to them the wisdom we've earned that isn't in
the texts books. To see them as welcome colleagues rather than
competitors.
Don't short-change the most important talent you have: experience.
Paul Newman, the actor, was also a Grand-Prix race car driver. When
asked how he had beaten a field of 40 younger men in an important
race, he said: "Youth, stamina, and reaction time are no match for
the treachery of an old man!"
3. Yourself. You are your own stiffest competitor. You compete
with yourself when you lock-in to the successful formulas of the
past and become so enamored of your experience that you don't see
that the world has changed and that you also must change. The
medical profession does one thing right: continuing education. If
we are to build permanent products, it follows that you can't be do
next year what you did last year. And if you're doing something
new, it's unlikely that you'll use the tools and methods that were
suitable last year.
3. Maintaining Competitiveness
3.1. Maintaining?
I wish that our concern were merely maintaining our competitiveness.
To maintain something, you first have to achieve it.
3.2. As a Community
Here are some things that we can do, and equally important, stop
doing as a community to assure the permanence of software and to try
to earn some of that missing love.
1. Standards. We have no choice about standards. If we don't
create and follow them, the world will create them for us and force
us to use them -- no matter how ill-conceived or inappropriate those
standards might be. I read that the Japanese representative to the
ISO 9003 committee asked how many participants (besides himself) had
any personal experience in software development. The answer was
appalling. Other than the Japanese and a handful of Americans and
Germans, no one involved had any software experience at all. Yet
they blithely set a standard that may saddle us for decades.
The lesson is crucial and the message is clear. Either we do it, or
they will. We know how good software should be developed. We know
the tools to use. It's time we stopped balking at standards for
some momentary advantage over a supposed competitor. It's time we
accelerated the poky standardization process. It's time to boost
the standards to reflect what they should be, the best accepted
practices rather than the least common denominator.
Standards are a community affair, but organizations and individuals
take action. Stop looking for ways to end-run or avoid the
standards and start finding ways to implement them, and more
important, to bring them to the level of excellence they must have
if we're not to have worse standards imposed on us.
2. Stop the Features Wars. Learn from other industries. You
can't escalate feature upon feature without end. You won't compete
by putting in yet more gizmo that users don't want and don't
understand. That software evolution direction has run its course.
Stop trying to make every package be everything to everyone. We
don't need a word processor in a spreadsheet or a spreadsheet in a
word processor. Pick a sharply defined set of related tasks and seek
excellence at those. Remember the amphibious car and the convert-
a-plane. There are better alternatives to market penetration than
fratricidal feature frenzy.
3. Stop the Model Years. Remember the automotive industry's
annual model frenzy? As long as they were trying to come out with
something radically new each year, what we got instead of excellence
was tail fins and rearranged chrome lumps. The Japanese did away
with model years so they could concentrate on sound engineering and
continual improvement. We have our model years. The annual release
frenzy and COMDEX. Start products with an arbitrary release number,
such as 4.37. Don't promise radical changes and don't make them.
All releases become maintenance releases with only minor,
controlled, gradual, changes. A new, thoroughly tested, but
unannounced release every three or six months that's untied to media
events such as COMDEX. Maybe then we'll make schedules we can keep.
4. Rational, Rather than Fictional, Pricing. Software isn't free.
Neither is service. Neither should upgrades be. This change,
happily, is ongoing.
Get used to 900 numbers for service. Get used to paying $29.95 for
release download. As a community, do what we can to get the users
to accept this reality.
5. Debunk the Software Myths. Software was never perfect and
never will be. Stop feeding the press and users with myths such as:
"If only one character is wrong, the whole thing's bad." Stop lying
to them and to ourselves about bugs. If we don't change the users'
expectations about bugs, they'll hold us to an impossible task and
then hate us when we fail.
6. Cooperate. Community level cooperation through the interchange
of ideas, methods, and standards, is essential. That cooperation is
expressed by organizations, but starts with individuals.
3.3. As Organizations
If, in this section, I seem to be speaking only to commercial
software vendors (e.g., for PC software), I'm not. The commercial
software vendor is the best model for exploring competitive issues
because issues are clearer. But the internal software developer
such as the MIS shop is also a "vendor." Remember, the internal
"vendor" can be displaced by doing it differently -- by going to an
outside, commercial, software vendor. What can the organization do
to assure its continuance as a viable competitor?
1. Satisfy their needs. Earn their love by satisfying their
needs. Remember, their first choice is doing without, the second
choice is doing it differently, and only rarely do you lose to your
direct competitor. To satisfy their needs you have to learn them.
It isn't done by consuming martinis at COMDEX and listening to your
direct competitors' hype.
Use public opinion polling methods and experts. Create and
administer bias-free questionnaires. Instrument your software so you
can gather user-profile data. Do professional usability testing
(two way mirrors, video cameras, industrial psychologists, and all
that). But don't forget that what they want and need most is
anxiety-free products that really works.
2. Real Cost Accounting. Most software developers don't know what
software really costs. You need end-to-end, honest, cost accounting
so you can associate a true cost with every line of code and every
feature. Most cost-accounting practices for software today are
driven by tax laws and the stock market instead of engineering
reality. Such practices distort true costs. Without costs, you
can't evaluate benefit. And without that, you can't decide where to
put your limited financial and human resources. The usual
consequence of cost ignorance is not the wrong decision, but no
decision.
3. You can't have it all. There'll never be another Microsoft or
another Bill Gates. And even Bill Gates doesn't believe that
Microsoft can have the whole software industry. Do your thing and
do it well. Do it very well. If you're destined to become the
Microsoft of the 21st century, it will probably happen with or
without your attempting it -- more likely without.
4. Realistic Product Goals. No feature wars for the industry and
no feature wars for you. Push reliability, ease of use, hassle-free
installation, and excellent service, instead of chrome bumps and
tail fins. No more multi-function, do-everything products.
5. Exploit Technology. Most tool vendors would be delighted if
they only had to slug it out with direct competitors. Most of their
sales effort is in selling the idea of the tool, rather than their
version of it.
Commercial technology that can reduce your software development and
testing labor content, and therefore improve your productivity and
competitiveness is out there begging to be exploited. And, if
you've already incorporated such tools into your process, then there
are scads of research tools waiting to be commercialized. What
hinders development of commercial tools, especially test and quality
tools, is an unwillingness of organizations to invest in them. They
wont be commercialized until the tool vendors perceive a market.
How about saying to your favorite tool vendor: "You know, if you
brought out a firewall test maintenance tool, I'd love to be a beta
site."
6. Stop Schedule Fiction. If you're not regularly meeting your
schedules, you're not schedule-driven, but panic-driven. With
excellent tools such as COCOMO and minimal record keeping, there's
no excuse to not meet realistic schedules. If you're not fighting
the feature wars, not building for media hype, and have set rational
goals for each release, then you can meet schedules. Not just
occasionally, but always.
7. Education. The cost of the tool is the least of it. Tools
will be shelfware if workers aren't educated in their use. That
education is in several parts and you need all the parts. The
biggest cost of education is not the bucks you spend, but the time
your people spend. The education they need, from least to most
important, are:
a. Formal General Education. Organizationally paid graduate
courses is a typical format for this. Workers need general
background education to learn concepts that are prerequisite to
understanding new technology. If you want to learn about finite-
state machines and data flow, for example, a graduate course is
probably the best place. Such education is valuable, in a diffuse
sort of way, but changes very slowly. Contrary to popular myths,
formal education is usually ten or more years behind practice.
b. Industrial Seminars. Seminars on a restricted topic such as
quality assurance, testing, or object oriented design. This
education bridges the gap between formal education and practice. By
nature, industrial seminars are more reactive and up-to-date.
c. Technology Specific Training. Don't expect your people to
learn a new, powerful, but complicated technology without training.
Pick vendors who offer specific, hands-on training on their
products. And don't be upset if the training costs as much per seat
as the tool itself. Eventually, when you build up a cadre of savvy
tool users, you can do this training yourself.
d. Brown Bag Sessions. Get the local internal experts to tell the
rest about how they applied method X or tool Y and what they
learned. This is cheaper and more valuable than any external
training.
e. Screwing Around Time. The most important (and most expensive)
training of all is the worker's self-training. I call it "screwing
around time," because it looks like that's what they're doing; but
looks are deceiving. They're going through the very difficult
process of internalizing a new idea. Even a simple capture/playback
tool needs a few weeks of screwing around time. More complicated
tools and methods need more time. Such things aren't optional in
the armed services. They say: "You will learn tool X or Method Y if
you want to be promoted." And they're given the time and resources
needed to become fully capable. This time is, of course, considered
in any schedule.
7. Exploit Research. There's been much excellent research done in
testing, in quality assurance, in maintenance, and all the rest, but
it lies fallow and unused. The most common criticism I hear about
such research is that it was done on "toy software" rather than the
real thing. But our brilliant researchers aren't given the
opportunity to try it on something real. You want to get the drop
on your direct competitor? Adopt a researcher or endow a chair.
Bring a smart graduate student (and/or his professor) in for the
summer. Both they and your staff will be better for it. They'll
adapt their research prototype to your environment, train your
people in their use, all for pennies (even janitors cost more than
graduate students). For the price of a minor irritant and a few
thousand bucks you get a three-year head start.
8. New Directions. If feature wars stop, what keeps them buying
our product every year? Once they've learned the product, why do
they need to buy our training? You talk about product permanence
but where's our job permanence? The answer is that software must
evolve in new directions. Software evolution parallels hardware
evolution. Hardware, at first, evolved with ever fancier and more
complex instruction sets (and correspondingly more complicated
control logic). RISC (Reduced Instruction Set Computers) emerged
because a careful look at instruction usage statistics showed that
the complexity was misplaced. With a simpler instruction set built
over a more powerful infrastructure (stacks, registers, busses,
virtual memory support, etc.) it was possible to achieve higher
performance at a comparable cost. The same has been happening to
software. Ever-increasing complexity (feature wars), built over the
same old infrastructure. An analogous revolution is needed (and is
ongoing) in software.
My crystal ball is very hazy so I can't give you a definitive list
of alternatives for the new direction.
I'll discuss those I can see for the moment, which to some extent
or another, have been appearing in commercial software in the past
decade. I'm confident that once people recognize that new
directions are possible and essential, then there'll be so many
options that it will be difficult to choose among them. Here, based
on current trends in commercial software, are some possibilities:
a. Smart Software. This software learns how people use the
product and modifies itself to better match that usage. Some
examples: rearranged menus to bring the most frequently used
features to the top level; automatic default option definitions;
suggested alternatives that the user hasn't learned; automatic macro
construction and installation. All these, in one form or another,
exist in some commercial products. This is a new direction because
it creates adaptive software that continually and automatically
improves its utility and quality. And we've only scratched the
surface. Look for expert systems driven by user statistics.
b. Smart Customer Service. I don't know about you, but if they're
going to charge me $2/minute for 900-hot line service I surely don't
want to waste that time reading out my AUTOEXEC.BAT file to some
novice line-by-line. My call to the hot line is made from within
the application and all pertinent configuration data (my name,
account number, operating system, hardware, drivers, etc.) are
automatically uploaded before the meter starteverybody has to have a
modem to get service. I access this through my HELP menu. Once
they've got the data, they call me when a qualified service rep is
available. No more waiting for hours on hold while listening to
music I hate. Announce this (really cheap) upgrade when you announce
the 900 line policy to ease the pain.
c. Object Linking Standards. Whether it's Microsoft's OLE or one
of a few comparable standards for porting data across applications,
this will become the norm. It will get rid of the import/export
hassle (except for older software). It will rid us of a redundant
spell-checker in every application and other consequences of multi-
functionality. How many megabytes will that save, I wonder? People
will buy upgrades for this alone.
d. End of the Paper Instruction Manual. The only reason for paper
instruction manuals these days is as a deterrent to piracy. That's
no longer valid. CD-ROM is effectively mandatory and can say goodbye
to paper manuals. Help files are getting bigger and better. But
they're still not where they should be (really good indexes,
hypertext, complete bug lists, workarounds, etc.). Help systems
must cover every feature provided by the package, not just the most
popular features. If you charge for customer service, you have to
provide good help systems. A CD-ROM with a few hundred megabytes
can do that. It saves on junk calls during the warantee period,
it's cheaper to manufacture and ship than paper. And it's no hassle
to pop in the CD to get more detailed help.
How about some real tutorials instead of the sugar-and-spice
confections we get now? Three levels, at least: novice,
intermediate, advanced. The novice level is the junk we have today,
that assumes that you know nothing (for example) about computers,
word processing, or Windows. The next level assumes you know all
three and leads you through specific examples of doing the things
(based on statistics and usability testing) that most users new to
the product need to learn. The advanced level is keyed to the help
files and provides at least several worked examples for every
feature and for the most common feature combinations. Where
possible and effective, interactive lessons with correction and
feedback (written for adults, please)?
e. Bullet Proofing. We can live with crashes if data aren't lost
or corrupted and if recovery is painless. Add 10% to 20% to the
software to make it bulletproof, both from internal bugs and from
being stepped on. We've known how to do this for on-line systems
for years. Expect to see more of this stuff in ordinary software.
f. Automated User Profiles. Automated profiling doesn't benefit
the user directly. Indirectly, however, when such data are gathered
and collated from many users, and used to guide the design, the
result is a refinement of the software that the user will be happy
to pay for, even if there are no fancy new features.
g. Automated Bug Reporting. Every restart/recovery provides some
data about the bug that caused it, whether it's an internal bug or
whether some other software stepped on you. Gather that data and
report it directly into the anomaly tracking system via an 800 line
and the modem that everyone has. Again, not a direct benefit, but a
long-term, indirect benefit.
3.4. As Individuals
What can you do to increase your personal competitiveness?
1. Education. The education options listed under organizational
strategies for competitiveness also apply to individuals. If your
organization provides them, great: exploit those opportunities. But
if the employer doesn't provide them, you must take the initiative.
You can't afford to risk your career on the policies of any one
employer. At least be sure to include education options in how you
rate your existing or prospective employer. Take night course,
read books, read technical journals, join engineering societies and
attend local chapter meetings. Set yourself an annual self-
education goal: "This year I'll learn all about . . . " An evolving
profession means lifetime education -- of which, self-education is
the most difficult but most valuable. "He who does not increase his
knowledge decreases it. If I am not for myself, who is?"
3. Championship. We don't lack technology that can make us
more competitive: we lack technology champions. Technology doesn't
get deployed in an organization by magic or by management dictate.
It gets deployed only when it has champions. If you aren't going to
champion new technology, who will? "And if not now, when?"
========================================================================
SQRL Report No. 17: Formal Verification of Timed Transition Models
by Hong Zhang
Abstract: Labeled Transition Systems (LTSs) are used to express
specifications and implementations of software. State-Event Labeled
Transition Systems (SELTS's) extend LTS's by adding a state output
map and an event map. A Timed Transition Model (TTM) is a timed
extension of SELTS. The extension involves lower and upper time
bound constraints and transitions, that relate to the number of
occurrences of the special transition tick. A TTM can be described
as a SELTS with a timer attached to each different transition, so
that we can specify the time requirements of the model. This thesis
gives the definitions of invariants, strong equivalence and weak
equivalence for SELTSs and TTMs in PVS. It also provides a unified
modeling environment for SELTSs and TTMs in PVS which allows the
user to specify them easily. Further, the thesis illustrates the
use of the modeling environment in PVS to prove invariants, weak
equivalence and strong equivalence of SELTSs and TTMs by providing
one example in each category. Finally we use our modeling
environment to formalize and verify the correctness on an industrial
real-time controller.
Our method has the advantage that is simplifies the procedure for
translating SELTSs and TTMs into PVS. A disadvantage is that it
still needs a number of interactions between the user and PVS,
although some of theses could be considered as routine work.
The web address for downloading reports is:
<http://www.cas.mcmaster.ca/sqrl/sqrl_reports.html>
========================================================================
Conference on E-Commerce Technology (CEC'04)
July 6-9, 2004
Westin Hotel, San Diego, California, USA
http://tab.computer.org/tfec/cec04
Sponsored by IEEE Computer Society Task Force on Electronic Commerce
California Institute for Telecommunications and Information Technology
IEEE CEC'04 is the 6th annual event (formerly WECWIS) and the primary
forum for the exchange of information regarding advancements in the
state of the art and practice of e-commerce technology and Web-based
information systems.
CEC'04 will consist of tutorials, invited talks, paper
presentations, panel discussions and workshops. Submissions of high
quality papers describing mature results or innovative work are
invited.
Topics for submission include but are not limited to:
* Business process integration and management
* Business intelligence, decision support and data mining in e-commerce
* E-Commerce architecture and enabling technologies
* E-procurement and auction systems
* Grid services and service-oriented software architectures
* Intelligent e-commerce system & agents
* Multimedia web services & applications
* P2P & its application in e-commerce
* QoS e-commerce support & monitoring
* Real-time Internet technologies and scheduling protocols
* Security & trust issues in e-commerce
* Transaction & work-flow management
* Web services & middleware
General Chairs: Mei-Chun Hsu, CommerceOne Liang-Jie Zhang, IBM
Program Chairs: Martin Bichler, Technical University of Munich
Jen-Yao Chung, IBM
========================================================================
eValid: A Quick Summary
http://www.e-valid.com
Readers of QTN probably are aware of SR's eValid technology offering
that addresses website quality issues.
Here is a summary of eValid's benefits and advantages.
o InBrowser(tm) Technology. All the test functions are built into
the eValid browser. eValid offers total accuracy and natural
access to "all things web." If you can browse it, you can test
it. And, eValid's unique capabilities are used by a growing
number of firms as the basis for their active services
monitoring offerings.
o Functional Testing, Regression Testing. Easy to use GUI based
record and playback with full spectrum of validation functions.
The eVmanage component provides complete, natural test suite
management.
o LoadTest Server Loading. Multiple eValid's play back multiple
independent user sessions -- unparalleled accuracy and
efficiency. Plus: No Virtual Users! Single and multiple
machine usages with consolidated reporting.
o Mapping and Site Analysis. The built-in WebSite spider travels
through your website and applies a variety of checks and filters
to every accessible page. All done entirely from the users'
perspective -- from a browser -- just as your users will see
your website.
o Desktop, Enterprise Products. eValid test and analysis engines
are delivered at moderate costs for desktop use, and at very
competitive prices for use throughout your enterprise.
o Performance Tuning Services. Outsourcing your server loading
activity can surely save your budget and might even save your
neck! Realistic scenarios, applied from multiple driver
machines, impose totally realistic -- no virtual user! -- loads
on your server.
o Web Services Testing/Validation. eValid tests of web services
start begin by analyzing the WSDL file and creating a custom
HTML testbed page for the candidate service. Special data
generation and analysis commands thoroughly test the web service
and automatically identify a range of failures.
o HealthCheck Subscription. For websites up to 1000 pages, eValid
HealthCheck services provide basic detailed analyses of smaller
websites in a very economical, very efficient way.
o eValidation Managed Service. Being introduced this Fall, the
eValidation Managed WebSite Quality Service offers comprehensive
user-oriented detailed quality analysis for any size website,
including those with 10,000 or more pages.
Resellers, Consultants, Contractors, OEMers Take Note
We have an active program for product and service resellers. We'd
like to hear from you if you are interested in joining the growing
eValid "quality website" delivery team. We also provide OEM
solutions for internal and/or external monitoring, custom-faced
testing browsers, and a range of other possibilities. Let us hear
from you!
========================================================================
The First IEEE International Workshop
on Mobile Commerce and Services (WMCS)
The wide deployments of wireless networks and the explosive growth
in the number of mobile users have created a very strong demand on
burgeoning mobile commerce applications and variety of mobile
services that deliver contents. According to Nokia, there are 1.4
billion mobile phone users in the world and the number is increasing
rapidly. In Europe and Asia, transactions of mobile commerce and
services are reaching billions of dollars per year. The First IEEE
International Workshop on Mobile Commerce and Services (WMCS) is the
forum to discuss innovative ideas in creating cutting edge mobile
commerce systems and wireless information services, and to exchange
information regarding advancements in practice of mobile commerce
and services. The target audiences will be researchers, scientists,
software architects, and industry professionals who need to be
acquainted with the state of the art technologies and the future
trends in mobile commerce and wireless information ser! vices. The
event will take place in San Diego, California, USA on July 6 2004.
IEEE WMCS 2004 will be held in conjunction with The International
Conference on Electronic Commerce (IEEE CEC 2004).
Topics of interest include but are not limited to the following:
Wireless application system infrastructures for mobile
commerce systems and wireless services applications
Mobile portals, context-aware and location-based
mobile commerce and services
Novel mobile commerce applications and mobile services
Mobile commerce middleware and frameworks
Workflow management and business processing for mobile
commerce and information services
Agents for mobile commerce and services
Mobile database systems and transaction services
Security and privacy in mobile commerce and services
Mobile payments protocols and systems
Mobile web enterprise systems and services
Wireless advertising systems and marketing solutions
Case studies and first-hand experience reports in
mobile commerce and information services
Workshop Co-chairs:
Jerry Gao, San Jose State University
<jerrygao@email.sjsu.edu>
Simon Shim, San Jose State University
<sishim@email.sjsu.edu>
========================================================================
========================================================================
------------>>> QTN ARTICLE SUBMITTAL POLICY <<<------------
========================================================================
QTN is E-mailed around the middle of each month to over 10,000
subscribers worldwide. To have your event listed in an upcoming
issue E-mail a complete description and full details of your Call
for Papers or Call for Participation to <qtn@sr-corp.com>.
QTN's submittal policy is:
o Submission deadlines indicated in "Calls for Papers" should
provide at least a 1-month lead time from the QTN issue date. For
example, submission deadlines for "Calls for Papers" in the March
issue of QTN On-Line should be for April and beyond.
o Length of submitted non-calendar items should not exceed 350 lines
(about four pages). Longer articles are OK but may be serialized.
o Length of submitted calendar items should not exceed 60 lines.
o Publication of submitted items is determined by Software Research,
Inc., and may be edited for style and content as necessary.
DISCLAIMER: Articles and items appearing in QTN represent the
opinions of their authors or submitters; QTN disclaims any
responsibility for their content.
TRADEMARKS: eValid, HealthCheck, eValidation, TestWorks, STW,
STW/Regression, STW/Coverage, STW/Advisor, TCAT, and the SR, eValid,
and TestWorks logo are trademarks or registered trademarks of
Software Research, Inc. All other systems are either trademarks or
registered trademarks of their respective companies.
========================================================================
-------->>> QTN SUBSCRIPTION INFORMATION <<<--------
========================================================================
To SUBSCRIBE to QTN, to UNSUBSCRIBE a current subscription, to
CHANGE an address (an UNSUBSCRIBE and a SUBSCRIBE combined) please
use the convenient Subscribe/Unsubscribe facility at:
<http://www.soft.com/News/QTN-Online/subscribe.html>.
As a backup you may send Email direct to <qtn@sr-corp.com> as follows:
TO SUBSCRIBE: Include this phrase in the body of your message:
subscribe <Email-address>
TO UNSUBSCRIBE: Include this phrase in the body of your message:
unsubscribe <Email-address>
Please, when using either method to subscribe or unsubscribe, type
the <Email-address> exactly and completely. Requests to unsubscribe
that do not match an email address on the subscriber list are
ignored.
QUALITY TECHNIQUES NEWSLETTER
Software Research, Inc.
1663 Mission Street, Suite 400
San Francisco, CA 94103 USA
Phone: +1 (415) 861-2800
Toll Free: +1 (800) 942-SOFT (USA Only)
FAX: +1 (415) 861-9801
Web: <http://www.soft.com/News/QTN-Online>