[Top] [All Lists]

Re: [ontolog-forum] Characteristics of a Software

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Tue, 01 Apr 2008 16:42:41 -0400
Message-id: <47F29E41.7030908@xxxxxxxx>
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)

<Prev in Thread] Current Thread [Next in Thread>