2.1. |
In the first instance the reference shall read: "ARRAY Development
(Canada) Inc.". |
2.2. |
In all subsequent instances, the reference shall read: "ARRAY". |
2.3. |
References to DeLiberation in any software or documentation
shall always be DeLiberation™ Extranet. |
2.4. |
Where the ARRAY corporate logo is required, it shall be
a copy of, link to, or reference to: http://www.ARRAYdev.com/graphics/array.gif
|
2.5. |
Where the DeLiberation™ Extranet logo is required, it shall
be a copy of, link to, or reference to: http://www.ARRAYdev.com/commerce/delibadmin/delib2.gif
|
2.6. |
All references to ARRAY's domain shall read: "ARRAYdev.com",
i.e. URL references shall read http://www.ARRAYdev.com/
and email addresses shall read firstname.lastname (at) ARRAYdev.com or array (at) ARRAYdev.com
. |
4.1 |
All software, applications, modules, and documentation
developed under contract to ARRAY Development (Canada) Inc. are the exclusive
property of ARRAY Development (Canada) Inc. |
4.2 |
All software will be developed for the 32 bit mode Microsoft Windows
NT 4.0 environment. |
4.3. |
All software which makes use of electronic mail must use
SMTP for the transmission of mail. POP3 should be used for incoming mail |
4.4 |
All software will be written as scripts for Perl 5.X where
appropriate. Microsoft Visual C++ version 5.0 should be used where Perl
5.X is not appropriate. |
4.5 |
All software, documentation, and help files will be maintained
by ARRAY using a software code management system. |
4.6. |
The list of application, module, and global variable names
which are "in-use" or "reserved" by ARRAY for reference by developers is
given on page http://www.arraydev.com/commerce/delibadmin/delib2/in-use.htm. |
4.7. |
A standard Windows NT command line interface and parameter
definition which all developers will use to preserve uniformity across
ARRAY applications is given on page http://www.arraydev.com/commerce/delibadmin/parametr.htm. |
4.8. |
All software which requires a user interface shall conform
to both the standard Windows NT 4.0 graphical user interface (GUI), and
the Windows NT command line interface. |
4.9. |
All basic forms shall be composed of four components:
HTML Documentation.
Basic HTML Forms.
Basic Perl form processing script (might be multi-page).
Sample Database.
|
4.10. |
All GUI windows must, by default, be 640 X 480 pixels in
size, unless the full content of the window can be displayed in a smaller
window. |
4.11. |
All GUI windows must be scalable. When the information viewed
exceeds the size of window, scroll bars should be used to control the information
visible in the frame. |
4.12. |
All help files shall conform to standard Windows NT 4.0
help files and libraries. |
4.13. |
Wherever possible, developers will make use of existing
ARRAY code and modules in developing new applications and modules. The
developer should request from ARRAY whether there is a source code for
existing modules that could be modified for new applications or modules. |
4.14. |
Modified modules and applications must be backward compatible
to the previous release. Modified modules and applications must pass all
tests defined for the previous release, as well as the tests defined to
validate the new functionality or expanded requirements of the current/new
release. |
4.15. |
All applications and modules must be delivered in source,
compiled code, and developer build libraries where required. |
4.16. |
All help files must be delivered in source, Microsoft help
file and help library format. |
4.17. |
Unless specified in the module specification, all documentation
must be provided in standard ASCII format. |
4.18. |
Each individual source code file, help file, HTML file and
ASCII file will contain a commented header with the following information
in the order listed below:
-
http://www.ARRAYdev.com
-
If applicable: Project Name.
-
If applicable: Project Version Number.
-
Application/Module/Document Name.
-
Application/Module/Document brief functional description.
-
Application/Module/Document version number.
-
Date of release:
-
Author:
-
Description of release/modification:
-
Version number, Date of Release, Author, and description of release/modification
shall be maintained in reverse chronological order so that the latest changes
appear first in the list.
-
The full ARRAY copyright notice as found in URL http://www.ARRAYdev.com/copyright.htm
|
4.19 |
Each software module, object, subroutine, procedure and function within
a source code file should have a header containing:
-
Brief functional description
-
Description of any special algorithms used
|
4.20 |
All software must be delivered with compilation instructions,
which will produce an identical result to the delivered compiled code.
Verification will be made by ARRAY upon receipt of all code. |
4.21 |
All software/documentation/help files must contain the version
number assigned at the initiation of the project. Developers will append
a two digit (.xx) sub release number and increment the sub release number
with each transfer of the files to ARRAY. The developer sub release number
must be stripped upon official release of the software. |
4.22 |
No additional software other than a browser should be required by the
user to run these applications. |
5.1. |
ARRAY will provide the names of the projects and applications,
and, on occasion, modules that it requires to be developed. Where items
are not so named it will be the responsibility of the developer to create
names for applications, modules, functions, procedures, and variables. |
5.2. |
It is essential that developers do not use names that conflict
with existing module, application, and global variable definition names.
Developers must reference ARRAY's list of existing names to ensure that
conflicts are not generated. |
5.3. |
All names will be generated in accordance with "Hungarian
Notation":
Brief Description: http://www.eskimo.com/~scs/C-faq/q17.8.html
Expanded description: http://www.unf.edu/cis/cliff/unix/hungarian.html
Sample Implementation: http://www.sandia.gov/GIS/tech/avcsus.htm |
5.4. |
All variables will be defined within the source code in
alphabetical order by type, and in alphabetical order within types. |
6.1. |
All applications must include the project name and version
number, and the application name and version number in the Help About box. |
6.2. |
All applications must include a Registration menu item under
the Help box that permits the client to register the application using
ARRAY's electronic software distribution control system. Detailed references,
registration information, function calls, verification calls, etc. will
be defined when a product is selected. |
6.3. |
All applications must be multi-threaded to support concurrent
use. |
6.4. |
All applications must be delivered with a suite of tests,
results and documentation on how to run the test and reproduce the test
results. The test results must reflect conformance to the application requirements. |
6.5. |
All applications must be delivered with both Install and
Uninstall options through the Installation Wizard. |
6.6. |
In the case of a system application, the Uninstall option
must completely remove the application, registry keys, files, directories,
startup folders, etc. from the client system. |
6.7. |
In the case of a user application, the Uninstall option
must completely remove references to the application, registry keys, files,
directories, startup folders, etc. from the user's environment on the client
system. If the user is the only or last user with the application installed,
the Uninstall option must completely remove all of the above items from
the client system. |
6.8. |
System applications will enter options in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\ARRAY\ProjectName\Version\ApplicationName\Version. |
6.9. |
Initial installation of a system application must, wherever
possible, absorb all system and user options as defaults during the installation
process. For example, if an application has a printer setup, during installation
it will set the application printer options to the Windows default printer
options. |
6.10. |
User applications will enter options in the registry under
HKEY_CURRENT_USER\SOFTWARE\ARRAY\ProjectName\Version\ApplicationName\Version. |
6.11. |
In both system and user applications, upgrade installations
to an application will "absorb" the options currently set in the previous
version of the application. |
6.12. |
All applications will be built with allowance for ARRAY's
electronic software distribution control system. Detailed references, function
calls, verification calls, etc. will be defined when a product is selected. |
6.13. |
All Installation procedures will be designed to incorporate
a registration process for validation by ARRAY's electronic software distribution
control system. Detailed references, registration information, function
calls, verification calls, etc. will be defined when a product is selected. |
6.14 |
An Installation Wizard must be provided to perform the initial software
installation of the module |
6.15 |
The module must be fully operational once the System Administrator
has run the installation wizard. |
6.16 |
Every time a user incurs an application error, an email message will be passed to the the person responsible for maintaining the application. The email address will be application-maintenance@client.com, unless otherwise specified.
|
6.17 |
The background colour for each HTML page used by the application will by "#FFFFFF". |
6.18 |
The background colour of each input form used by the application will be "#FFFFEC".
|
6.19 |
Each application will have a questionnaire that prompts the user for feedback on the quality and usefulness of the application.
|
7.1. |
All modules must be re-entrant. |
7.2. |
All modules that perform data conversion must validate the
input data before conversion and, on validation failure, return a specific
error code indicating the data was invalid. |
7.3. |
All modules must be accompanied by documentation declaring
the parameters to be passed, the type of data to be passed, the resultant
data to be returned, and a complete list of error codes that could be returned. |
7.4. |
All module source code must include a separate header file,
or a reference to header file(s), where data types of parameters, returned
data and error return codes are defined (example). |