1. Prove your concept.

You may be familiar with the problem at hand, but do not have the knowledge to write the implementation plan or the specification. For example, you may not know the performance implications of a proposed change on a large data set; you may not know if proposed changes are possible or fit with the character of the Archibus environment; you may not be certain you have staffed the project with all of the database administration skills you will need; or, you may not be able to estimate the time necessary for a particular task.

In these cases you will want to go through a proof-of-concept exercise. This is a small prototype trial examining the unknown points. For benchmarking, you may run an automated routine over the weekend to create one table with the size and indexing of the proposed tables. You may create view actions with the proposed behavior to illustrate how the view interface will work. Or you may move a sample project onto an Oracle server to exercise the necessary database administration skills.

The intent of the proof-of-concept exercise is simply to provide planning information. You should not expect that the exercise will deliver any significant portion of the implementation.

2. Develop an implementation plan.

While a customization may be the key piece to a site's implementation, it always falls in a larger context. The implementation plan ensures that you have assigned responsibility for all tasks required to make the automation project a success.

Consider these questions when reviewing an implementation plan:

• Who will train the users of the system?
• Is there data-entry work, such as facility reference drawing development, that needs to be performed before the system goes into operation?
• Who will perform the initial installation? How about the installation on additional workstations?
• Who will manage regular back-ups and other database administration, such as rebuilding databases? Is this the responsibility of the facility department, MIS, or a contractor?
• Who will maintain the communications log for the project? Who is responsible for keeping customizations on file?
• Who is the contact for support on the customization, and under what terms is that support offered?

3.  Develop your specifications .

For corporate developers, the specification is a tool to explain to the in-house clients what the system will do and how it will look.

For contractors, the specification has an additional purpose. By documenting the changes involved precisely, the contractor has a definition of the deliverable necessary to satisfy the contract. The specification defines when an invoice is appropriate and defines what additional requests need an amendment to the contract.

In either case, it is important that the client understands and signs off on the specification as a clear statement of the goals of the project.

4. Implement your changes.

In this phase, you actually implement the planned features by making changes to the schema and/or developing code that provides the required functionality. Depending on the customization, this may involve developing new views (.avw) or JavaScript (.js) or workflow rules with associated java code.

5. Document your changes.

Any system must be delivered with documentation as to its use, but there are some other documentation tasks to consider. For instance, you also need documentation on the changes themselves. If you are a client of an outside contractor, you will want this documentation to make certain you can maintain the customization even if you change vendors. If you are a contractor, you will want to be able to quickly review changes at a site if you are asked to provide extensions to the work or update the work to a newer release of software.

Another important type of documentation is a revision history--a list of changes and the version in which the changes were implemented. A related issue is keeping a series of copies of the customized files for reference.

6. Test your project.

Testing is an art and study in itself; however, a few things to think about when testing your application.

• Do you have a check-list of test cases that define an objective, repeatable standard of quality for your customization?
• Do you have a person separate from the implementer performing the testing?
• As a baseline, do you check at least every view, every view statistic, every action, every view action, and every dialog control?
• On complex sections of code, can you have another programmer perform a code inspection looking for uninitialized variables, non-terminating loops, or errors in type conversion, computations, comparisons, or flow-of control?
• For each action that performs a computation, have you tested all equivalent groups of input boundary conditions? For instance, for a record set that loops though a numeric field from a table and sums the results, did you test the result with no records, with one record, with a very large number of records? Did you test the result with zero as an input value, with null as an input value, with negative values? Did you test with fractions? Is rounding an issue?
• For each dialog control, what happens if you enter blank values, negative values, values of the wrong data type, very large values, strings that overflow the control, multi-line strings?
• If you are delivering on multiple servers, have you run the check-lists against each server?

7. Implement a pilot project.

Changes of any complexity you will wish to run on a pilot basis before converting your production database to the new format.

The pilot stage lets you shake out any issues concerning converting the entire data-set or explaining the usage to the operators.

8. Implement your production project.

Once you have completed your pilot, back up your production database and schema, convert your production data to the customized schema, and start the customized schema on the server dedicated to daily use.