Schiffel, Jeffrey A wrote: (01)
> The difference between software and the underlying mathematical
> structure - e.g. algorithms and logic -- must be distinguished. The
> software can age and become obsolete. The underlying logic probably does
> not, although the subject for the applied logic might become dated. (02)
If the software correctly implements the underlying mathematical
algorithms and logic, and those algorithms and logics were correct with
respect to the problem space, the software does not "age". (As Jeffrey
observes, a running instance of the software might age, although I would
argue that a correct implementation does not age while running unless
the platform ages while running, but the reference code, and even the
reference executable image, does not.) (03)
In those cases, the software "ages" when one of the following happens:
- the target problem space changes ("the subject becomes dated")
- the platform (hardware or operating system) changes, and the
software is no longer a correct implementation on the new version of the
running platform
- the software is modified to improve performance (rather than results) (04)
The issue is what properties of the software you want to distinguish
from the algorithms. (05)
Most software "ages" because either the algorithms it implements were
incorrect for the problem space, or the implementation of the algorithm
was faulty. So it gets "repaired", which is not the same as "corrected". (06)
Mathematical software tends to be correct after the initial shakedown.
But it is sensitive to platform changes, which changes the relationship
between the algorithm specified in the software and its physical
implementation, which is the interpretation of that specification by a
changed environment. In effect, the meaning of the language changed,
while the words remained the same. (07)
But most correct software "ages" because of the changes in the
expectations of the users. The problem space changes, perhaps subtly,
and the original algorithm no longer applies. Or the relative use of
time, memory and I/O becomes unacceptable when the relative amounts
available change disproportionately. (Software that was designed to run
in a 250K memory space does a lot of I/O to manage memory, and now
memory is 8 times the size it was 10 years ago, but I/O is only 2 times
as fast. So the still correct software is now "slow".) (08)
The elephant in the room is the highly complex platform used to run
"desktop" or "laboratory" software. Nothing is reliable because the
platform itself is not. And it is highly unstable. The great new
feature is that it modifies itself every week, like bacteria. So
everything on that system is aging on a weekly basis! (09)
By comparison, if you look at the 1M lines of software in your
automobile, or the 8M lines of software in a commercial aircraft, you
will see that the underlying platform is the 6th or 7th generation of
carefully controlled growth of a software/hardware architecture that
began very simply 35 years ago, and has been rigorously tested in every
replacement and every new feature. And in large measure, the same was
true of cell phones until very recently. Because the software is
correct and stable all the way down, the only aging behavior is
obsolescence -- what it was designed to do is no longer done (that way),
or the device it was designed to work with is no longer used. But that
is almost never the case in the same automobile or phone, and only
happens occasionally in civilian aircraft. The 10-year-old auto and the
20-year-old aircraft still operate with the same software -- it doesn't age. (010)
But for a vendor to make this commitment requires that the cost of
failure in service be much higher than the cost of longer time to
market. And the big software houses have never observed significant
cost from in-service failures. (It will be interesting to see whether
Sarbanes-Oxley and its EU counterparts change that. How can a business
guarantee implementation of a regulation in software if the software
platform makes no warranty that it performs as advertised?) (011)
-Ed (012)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (013)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (014)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (015)
|