logo Professional
Database
Developers
Aldex Software Ltd.
Development Standards


Introduction
This page summarises the standards to which we work when developing Access database software and is taken from our full 'Access Database Development Standards' document. Our standards for other development environments, such as SQL Server, are similar but with variations to take account of differences in the products. See also our Best Practices page which looks at some of these items from a slightly different viewpoint.

 
All software is to be developed using industry standard Best Practice methods - broadly as described by Getz, Litwin and Gilbert in the Access Developer's Handbook; ISBN 0-7821-1941-7.
 
 
All software is to be wholly developed in-house by experienced Aldex personnel. Software will not be subcontracted out to third parties (either within the UK or in third world countries such as India) as we believe that this causes an unacceptable loss of control over the quality and consistency of the application. For the same reason trainees are not to be used on client's work.
 
 

Clients are to be fully involved in the development process. Regular updates are to be sent to them and they should be encouraged to provide feedback and to talk to our designers and programmers.
 

 
Naming of variables, forms, tables, etc. will follow a modified Leszynski/Reddick convention. e.g. tables to start with 'tbl', integers to start with 'int' (unless modified by a prefix for Scope or Lifetime).
 
 
All names will consist exclusively of the characters a-z, A-Z 0-9 and the underscore ( _ ). All punctuation marks and spaces are prohibited. Names will use 'Camel Caps' formatting.
 
 
Databases will be designed according to the relational model and will be normalised to the Third Normal Form (unless deliberately 'bent' for performance or other reasons).
 
 
Code will be commented, indented and laid out in a logical, readable manner.
 
 
All variables will be explicitly declared. The 'Option Explicit' statement is mandatory in all declaration sections. All declarations will occur at the top of the relevant procedure.
 
 
All procedures will include dedicated error processing and error logging routines.
 
 
Macros will not be used due to their inherent problems with error trapping and debugging. Instead, all processing will be undertaken using VBA, VB.NET or T-SQL as appropriate.
 
 
All databases, apart from the most trivial, are to be split into separate front and back ends and should include attachment checking and reattachment procedures.
 
 
Full source code should be included with all systems. Senior staff/developers at the client's company, who have the necessary authority, should be given access to all parts of the supplied systems.
 
 
Any changes to the agreed specification must be made formally in writing via a Change Request document. Change Requests may have both Cost and Time implications which you must accept before the additional work is carried out.
 
 
All software will be Year 2000 compliant.
 
 
All systems will be regularly checked for viruses.
 
 
All applications will undergo Quality Checking and Testing by a Senior Developer prior to release using our 37 point Quality Checklist.
 
 
In the event that any bugs caused by Aldex are subsequently discovered then they will be corrected free of charge for the lifetime of the application.

Contact Us...
Please feel free to contact us if you wish to discuss this further or if there is anything that we may be able to help you with.

Separator
Copyright ©2002, Aldex Software Ltd.

logo
Return to front page