Feb
12
Written by:
Hall
2/12/2010 7:58 AM
While it is generally recommended to utilize as much as possible the “best practices” employed in the QAD Enterprise ERP package, more often than not this is not possible. Most companies have proven and successful business processes or key reports that just are not addressed with standard QAD but can be incorporated into the overall package in a cost effective manner. This opens the door for customization and report modifications – a process that must be completed in both a cost effective and efficient manner. Tight functional specs and testing by savvy personnel ensure a smoother process from beginning to end.
The development methodology for developing Functional Specifications & Testing typically follows this path:
1. Define User Requirements – resulting in documented and approved Functional Spec for management’s approval. The due diligence in the definition stage should include the following:
• Business Reason – “Why”
• Assumptions & Inputs
• Expected Results from Testing
2. Development & Unit Testing – After approval for development, the developer uses the functional spec to code, design and provide initial testing of the program. Next, the first pass of the program is loaded into a ‘Test’ environment and reviewed by the functional consultant/business analyst. Often times this is iterative, but a tight functional spec will limit the “back and forth” between the developer and the consultant/business analyst.
3. Once the Unit Testing is complete, if required, we will run a full System Integration Test, especially for interfaces between systems of additional functionality. Often times report modifications do not require the same level of testing – that is, extensive and detailed – as custom programs. Nonetheless, Full System Integration Testing will often require “back and forth” between the developer the analyst. This is normal but the changes and the expected results must be documented.
4. Once the System Integration testing is complete, User Acceptance Testing (sometimes referred to as a Conference Room Pilot) is conducted with the end user community or their key representatives. This is the final acceptance by the user base. Any changes to the ‘core’ custom program must be documented, re-tested and presented again for user acceptance testing.
5. End User Procedures are developed, if required. Typically the Reports do not require procedural documentation (but can…). Maintenance programs will almost always require documentation for successful implementation and future training.
6. End User Training. Key users and power users are trained to ensure a smooth cutover.
7. Promote Custom Program/Report to Production, and
8. Cutover/Go Live.
Logan Consulting has a significant amount of experience with assisting companies in their custom program and report additions – both functional/testing and technical/programming. We apply our strong project methodology and testing process to ensure the customization project is completed correctly on time, within scope and on budget.