|
Frequently
Asked Questions
Who Owns the Copyright?
The ownership of the copyright passes to the client once the project is
paid in full. The ownership and the associated copyright privileges are
transferable once the project is paid in full. With the notable
exception of 4SC Ltd’s internal libraries, which are
provided royalty-free to the client provided they remain part of the
delivered software package. 4SC Ltd’s retains the
copyright of any internal library modules supplied.
Will
the system be built on top of a proprietary platform or system?
The system will be developed on commercially
available platforms such as Linux, Unix , Windows XP/Vista or bespoke
operating system. 4SC Ltd shall provide details of
the development environment. Any utilities and macros developed for the
project will be supplied together with the source code. Any third party
development products to be supplied, such as compilers, shall be
identified in the contract. The details of the development environment
will be supplied as a deliverable. If a commercially available platform
is to be utilised on the target hardware, then associated licence costs
(e.g. operating kernel) shall be identified.
The target hardware will be furnished either by the client or a COTS
(commercial-of-the-shelf). The source code for the project will be
supplied in full. 4SC Ltd’s library modules will be
tagged with copyright notification and this notification must not be
removed. The client may modify these modules should the need arise; any
such modification should for traceability be clearly detailed in the
file header.
4SC Ltd does not generally utilise third part
proprietary tools in its development. If 4SC Ltd is
required to utilise any such proprietary tools, then these shall be
procured by the client (for utilisation by 4SC
Ltd). for importing into the new system.
Will
the system use or depend on third-party libraries or
systems?
If the project utilises third party software
or libraries, these will be clearly identified together with their
associated costs at the “Response to Tender” meeting..
Is
the source code configured and traceable ?
The software developed by 4SC Ltd is placed
under configuration control once developed,
reviewed and tested. All subsequent amendments to the code are subject
to peer review and regression tests prior to final delivery.
Are
changes to the requirements allowed during development ?
As
a general rule yes. Though it is self-evident that any project must be
flexible enough to cope with changes to the requirements during
development, but it must be appreciated that such changes will impact
the design, timescales and possibly costs. Hence changes need to be
reviewed to asses the overall impact. This is generally not a
problem on smaller projects. On larger systems the aim is to avoid
"requirements creep",whereby the product continually evolves. The main
problem with "requirements creep" is that functional areas need to be
subject to repeated regression test in order to ensure quality of the
final product, this in itself results in delays and increase costs. Any
requirements changes resulting in significant design changes or
multiple minor changes, are usually best incorporated into a delta
release of the initial build. It these instances it is more economical
in time and costs to group several changes into a single release, hence
requiring a single regression test.
Is
the Development Environment Backed-Up ?
All developed software is backed up daily
and weekly at an off-site secure location.
Interfaces with the customer?
A senior manager or senior development
analyst with expertise talks to the customer to fully understand their
requirements and identify both the software and the target platform
requirements.
Is
there assistance with system integration and on-site support?
A senior developer will be assigned to
carryout system integration. This will possible involve the
configuration any client supplied hardware. If the product is to
integrate with your existing network, then this will require assistance
from the Administrator from the client’s IT department or someone with
administrator privileges. Long term on-site support will be discussed
during the "Response to Tender" meeting and costed.
How
long have they been in business?
4SC Ltd has been in
business since 1994.
How
many developers are employed?
4SC Ltd operates using highly experienced
sub-contract staff that have worked on major software systems. The
number of developers varies according to the workload. However no
contract shall be entered into until such staff have been acquired.
What
programming languages are used?
4SC Ltd can primarily
provide target code in Visual C++, C#, C++, C, Ada95, Visual Basic and
assembly language. But should a client wish to use any other languages
such as Delphi or legacy languages such as Fortran, Pascal then these
can be utilised.
Will
any form of logging be incorporated into the software to report bugs?
The code will have exception handlers built
in to help identify any faults or erroneous system behaviour. The
software will be supplied with the development debug software in place.
The user guide will identify how to enable full debugging software for
subsequent logging. This is in addition to any client requested
logging. 4SC Ltd software is designed to be robust
by design. For example all external data is validated on input. Any
invalid data is rejected at source and a hexadecimal message dump
available via the debug utility.
What
Warranty / Maintenance is offered?
The software will be delivered together with
the test result reports. The test reports shall detail the testing of
each of the functions requested. The company will fix all reported
in-scope faults for a period of 3 calendar months after delivery.
Support beyond this period will need to be discussed and agreed during
“Response to Tender” negotiations. The company will negotiate product
enhancements and out-of-scope fault fixes as part of a separate support
package. The interpretation of ‘in-scope’ fixes is where the system
fails as the result of a software exception, software crash or lock-up
as a result of an error in the supplied system or the supplied system
fails to satisfy a client’s specified requirement. All other types of
faults shall be considered out-of-scope (e.g. faults due to client
hardware failure or faults due to erroneous data from third party
sub-systems).
|
|
