Application Auditor provides a framework and methodology for project reporting, development, testing, and implementation in APPX environments. Projects can be requested by users, and then estimates can be created and submitted as projects. Tasks for each project can be assigned to different designers and individually tracked and documented on Project Worksheets. Finally Task Worksheets are used for user sign off and the automatic Design File Transfer of the Domains, Files, Fields and Processes that were modified as part of the related Project and Task.

The APPX environment has historically been superior as a tool for fast paced development, but doesn�t provide an adequate tracking of modifications for placement into the production environment. The dimension of this problem becomes ever more complicated as the number of developers and projects rise. Synchronization of production and development versions becomes more and more difficult as the pace of development rises, and the possibility of working on overlapping processes becomes inevitable.


The methodology provided through the use of Application Auditor may be seen as a significant departure from current development tactics. However, the benefits are many:

• Managers are able to see outstanding projects at a glance.
  
  
• Designer activities can be monitored.
  
  
• Historical inquiry of modifications may be reviewed either by project or by the specific object type and name. Project tasks can be transferred from one designer to another while maintaining standards and documentation regardless of the designer�s location or level of experience.
  
  
• Most importantly, enhancements are placed into production with greater reliability and accuracy.

As with every methodology there is a set of rules that must be adhered to in order to extract the best results. These rules and corollaries are as follows:

• No modifications are directly made in the production version.
  
  
• All development is performed in a test version.
  
  
• All development is tracked using Application Auditor
  
  
• All user testing is performed in testing environment.
  
  
• All production changes are transferred from the tested version.
  
  
• User approval is required for all transfer of production changes.

Training the designer staff to use this new set of development rules and how to navigate the new development procedures requires a new discipline. The retraining process may be met with resistance due to the perception of loss of effectiveness and responsiveness. Education and commitment to this methodology will prove otherwise.

There may be some resistance to implementing the Application Auditor methodology because of the perceived loss of the �Design and Run� methodology. This methodology is not lost but enhanced by the ability to have users participate in the testing and approval of modifications while protecting the live environment from costly programming oversights and enforcing synchronization of production and testing environments.

In many APPX environments modifications, both small and large, are sometimes performed in production environments. This style of work appears to provide responsiveness to the users. In fact, the speed at which many of these modifications are performed causes repeated rework and therefore a delay in delivery of a finished product. To paraphrase one Manager: "It only takes one �Oops� to wipe out all the �Atta Boy�s".

Setup for this new environment requires the creation of development and testing versions. Ideally each application should be set up in three different versions with separate databases. These three versions include Production, Acceptance Testing, and Development. Application development should always occur in the Development version. User acceptance testing always occurs in the Acceptance Testing version.

Finally, the Production version remains unchanged except for user tested and approved Project/Tasks.

To learn more about Application Auditor, download the Feature Guide.