Goto Computer Systems Notes main
page
3 The workstation(s)/computer system(s)
5 The use of 'standard' support packages and libraries
6 A potential customer makes an enquiry
7
The end-users view of the problems
End-users of software packages are often not aware of the problems faced by software houses implementing and supporting complex software across a range of computer systems and workstations. End-users of software are often worried by the time it takes for bugs to be fixed or new versions of a package to appear. Some packages may be available only under a particular operating system or on a certain range of computer systems or workstations. If a company uses a particular package on an IBM PC and wishes to run the same software on its mainframe computer system it may find that there is no suitable implementation available.
This paper discusses
the various problems faced by software houses which implement packages
across a range of computer systems and workstations and how these may effect
the staff responsible for computer system management.
Package A. Aimed at mechanical engineering design offices, to aid in:
1 the specification and design of a component in terms of geometrical shape, dimensions and materials;
2
the numerical analysis of how the structure of the component will perform
under operating conditions, e.g. loads,
temperatures;
3 the viewing in pictorial and graphical form of the results of the numerical analysis, e.g. stress and distortion.
Package B. Aimed at electrical engineering design offices, to aid in:
1 the specification and design of an electronic product in terms of the circuit and components;
2 the numerical analysis of the circuit under varying operating conditions;
3
the viewing in graphical form of the results of the numerical analysis,
e.g. frequency and phase response of an
analogue circuit.
In both cases if the results of stage 3 do not meet the performance specification the engineer would return to stage 1 to modify the design and repeat the process until satisfied.
The facilities of
the packages have been left vague so that problems of software portability
associated with project size may also be considered.
1 a screen capable of displaying graphical and pictorial information:
(a) the component or circuit in the drawing/specification stage ;
(b) the results of the analysis, i.e. graphs & drawings;
2 input devices for component and circuit drawing and entry of details, e.g. keyboard, tablet, mouse, light pen;
3 sufficient computing power to carry out the numerical analysis;
4 sufficient primary memory (RAM) to hold the program and data;
5 sufficient secondary memory (disk) to hold the program and component libraries.
It is clear that 'power' and cost of the computer system required to run the package will be a function of the size of the problem to be solved, i.e.:
Package A: is the product a door hinge or jumbo jet ?
Package B: is the product a small audio amplifier or a satellite system ?
For example, the complexity of the displayed images (which will be function of the size and complexity of the component) will effect the screen resolution and number of colours required. The possible range could be:
from (a) PC quality graphics
to (b) very high quality workstation 3D graphics of 2000*2000 (or even 4000*4000) pixels by 16 million colours.
Software houses may
wish to aim their product at a particular part of the market (e.g. small
companies using PCs) or produce a general package capable of solving a
range of problems on a range of computer systems (PCs, professional workstations,
minicomputers and mainframes).
1
If the customer base is to be limited to small engineering companies using
personal computers are the packages
to be implemented on:
(a) the IBM/PC, IBM/PC AT, IBM PS/2 ranges and compatibles ?
or (b) all PC's running the MS-DOS, OS/2 and Windows 95 operating systems ?
Is the graphical display assumed to be the display available with the machine
or would extensions or add-on
graphics cards be allowed, e.g. EGA, VGA, super VGA, etc. ?
2
Would an enquiry from a potential customer, no matter what configuration
of workstation/computer system, be
considered (even if an extra charge would be made for a one off implementation)
?
In the case of small software packages 1 (a) above could well be feasible. The large numbers of installed IBM PCs and compatibles form a defacto standard which could give a sufficiently large customer base. In view of the policy of many large corporate users who purchase only from IBM, it could be possible to restrict implementation to IBM machines alone. In cases where no machine dependent facilities were used at all, e.g. no graphics, it could be possible to target all machines running 'standard' operating systems such as UNIX, MS-DOS, OS/2 or Windows 95.
In general, in the engineering industry, there is no defacto 'standard' workstation or computer system (although UNIX is used on most professional workstations). CAD has been in common use (particularly in large companies) for the past twenty years, first on mainframes, then minicomputers and now on professional workstations and PCs. At one time the DEC VAX and Prime minicomputer ranges formed the host computer system in many design offices and initially some CAD software houses started out with packages implemented only on these machines. Today this is far too restrictive and could also cause problems when a customer who has a VAX wishes to run the package on some other system, e.g. IBM or Sun professional workstations. Therefore, unless the software house is producing a specialist package for a particular application running on a specified system, it is faced with implementing software on a range of configurations.
Another problem is
that whereas MS-DOS/Windows is currently the main operating system currently
used by small business machines (probably soon to change to Windows 95/NT)
the large range of host minicomputers used for CAD have no common operating
system. It is even possible for a computer system to run different operating
systems (possibly at the same time), e.g. an HP workstations concurrently
running UNIX System 5 and UNIX Berkley 4.2. UNIX has become available on
most machines with varying quality of implementation and performance, but,
even if it is available the customer may prefer the manufactures proprietary
operating system for reasons of efficiency.
The software house has to decide what system will be used for development of the packages (this could already be fixed if computer systems already exist in the company). The development system would be sufficiently powerful to run the end-user package plus modern software engineering support systems such as CASE (Computer Aided Software Engineering) tools and project management systems, e.g. IPSEs (Integrated project support environments).
The end-user packages could then be implemented on other workstation/computer system configurations by:
(a) using a customers facilities (assuming they are suitable);
or (b) by buying computer time from a third party.
If the software house has a number of different computer systems (from different vendors or with different operating systems) support has to be considered. Not only has one the problem of maintaining the hardware of different systems but there is the problem faced by systems staff who have to support a range of operating systems, compilers and other tools on different machines. To get staff skilled at this level of expertise may prove difficult and expensive.
In the case where
a customer has a workstation with uncommon specialist facilities, e.g.
real-time 3D transformations, which he wishes to use with the package,
a one off charge will have to be made for implementation. If a new implementation
is to be made and there are a large number of potential customers with
similar configurations no extra charge may be made.
1 business applications could use Cobol, Pascal, a 4GL, etc.;
2 engineering applications could use Fortran, C, C++, Pascal, Modula-2, Ada, etc.
Of major consideration is how well the ISO and/or ANSI standard of the language is observed. In the engineering environment Fortran has traditionally been the main programming language and is still very important (although many are now moving to C++):
1 engineers/programmers have many years experience in coding it;
2 there are many end-user packages already written in it;
3
there are a range of scientific/mathematical support packages, e.g.
NAGLIB, GKS, etc.
4.1 General guidelines on programming language
Having decided the target application area and computer configurations a programming language can be chosen which is the lowest common denominator, i.e. a compiler is available on all target computers. The program is then split up into two parts:
1
A machine independent component written in the standard language, e.g.
Fortran 90, ANSI C, etc. If the package is
to be mounted on a new computer configuration the machine independent source
code should only need compiling.
2 A machine dependent component which in the case of the CAD package splits up into two further components:
(a) routines for the particular computer configuration and operating system, e.g. special file I/O;
(b) routines to drive the particular graphics workstation.
Customers may have a number of workstations from the same vendor with a range of graphics facilities, e.g. up to 3D real time displays. In this case a number of implementations of stage 2 above will have to be carried out.
In cases where numerical analysis is being carried out accuracy of computations may be critical. Such sections of code would be included in the machine dependent section (e.g. could use DOUBLE PRECISION variables for calculations).
Although the code
is machine dependent it could still be programmed in the standard language
if suitable language extensions or facilities exist on the target implementation
(otherwise assembly language may have to be used). The reason for identifying
it as machine dependent is to make it clear to package implementors that
these routines have to be mounted on the machine with care and that they
could require modification. The machine independent part should only need
compiling.
1 routines for pictorial transformation and/or graphical display;
2 routines to solve mathematical algorithms;
The former could
well be available in graphics libraries such as PHIGS, GKS, etc. and the
latter in a mathematical library such as NAGLIB. If use is made of such
libraries when the CAD packages are implemented a problem then occurs when
the package is to mounted on a customers system. Unless the customer uses
the system for the development of similar programs it is very unlikely
that such libraries would be available. To purchase the libraries could
be expensive for one off implementations therefore software houses may
implement such facilities themselves.
1 What is the intended computer/workstation configuration ?
(a) is it a professional workstation running UNIX ?
or (b) is it an IBM PC compatible running Windows 95/NT ?
The customer may
already have a system or systems or may ask for advice on purchase of a
new one. If the configuration is one that is not already supported further
discussions will then have to take place to see if the software house
is willing to carry out an implementation and at what cost.
2
What network connection or mass storage transfer devices (disks magnetic
tape) are available to transfer the
program code to the and/or customers computer system ?
This may sound a
simple question but transfer of code between machines major problems.
Computer systems can be fitted with a range of disks and tape systems.
It could well be possible that the software house and the customer have
no common devices and recourse will have to be made to a third party. In
extreme cases some computer systems may be fitted with no exchangeable
devices at all, making use of a network to another site for disk backup.
If a new implementationis required, i.e. source code is being transferred
to the target system:
3 Is a suitable compiler available ?
If the customers
system is used purely for running end-user programs with no program development
being carried out it is unlikely that a compiler will have been purchased.
If not available a compiler will have to be purchased (possibly at a cost
of several thousand pounds on a professional workstation) or a third party
site used forimplementation and the resultant code transferred to the customer.
It can be seen
from the above discussion that software houses can face considerable problems
in implementing and supporting packages across a range of machines due
to variations in:
1
host computer systems not only in terms of manufacturer and model but also
processor power, memory size and
input/output devices;
2 host operating system and facilities;
3 quality of programming language implementation, i.e. compilers and library support;
4
graphics cards and displays used
End-users come to appreciate these problems when:
1
Implementations are not available for certain workstations. This can be
a problem when a company uses a
number of different workstations running a range of packages.
2
Updates or new versions of the packages are not available for some time.
When the software house brings out a
new version it will be mounted on the most popular workstations first.
Customers with a specialist workstation may
have to wait a long time and in extreme cases when a workstation is very
old the new version may never appear.
3
The porting of a complex package to a new system can take months. Software
houses have to consider whether
the potential market is worth it.consider it worth while porting either
because the potential market is reducing or the
system is not sufficiently powerful to support the extended version of
the package (in terms of processor power or
RAM capacity). Users end up being forced to scrap working systems if they
wish to use the latest versions of
software.
A combination of
these problems can occur when a company has several different workstations
running different versions of the same package.