P800 forms / template development

requirements for project to be outsourced. It entails development of a configurable (questionnaire style) forms system for the P800 platform. The project is in two parts. Phase 1 involves the production of a proof of concept level deliverable. This means the absolute minimum amount of work to be done in this phase, but what is done must be usable in the second phase. Phase 2 is the formalization of the tool suitable for production. This will be the subject of a formal detailed specification. Commissioning of the second phase is dependant upon acceptance of the first phase by the end user. /Outline/ (a more detailed treatment and some screen, file and form examples can be found in the attached document) ## Deliverables The concept is to have a database of several hundred uniquely numbered items/questions that can appear on forms, and a method to allow a small subset to be included in a data capture form(s). It is envisioned that the subset would be defined on a rudimentary configuration screen on a PC version of the system* and that subset given an ID (a form name such as Security 01). The subset would then be called up by name on the P800 as required and an instance created for completion by the user. For the proof of concept phase, only two forms are required. (Screen shots of their paper equivalents are provided in the attachment). *The rudimentary configuration facility on the PC is expected to evolve into a full management system in Phase 2. The Phase 1, proof of concept system is for a facilities management organization in UK. A database item/question might be "Standard of window cleaning", "Condition of equipment", "Property ID". Each item will have a range of possible responses. The range of responses might be: "Yes/No", "Unacceptable/Unsatisfactory/Satisfactory/Very satisfactory/Not Applicable", "Optional Text box up to 255 characters" and so [login to view URL] this item/question is to appear on the form, these choices will be offered in a drop down combo box. The fields can be designated as required or optional. The user should be able to return to the form at anytime until the commit stage to alter answers. The timestamp will be that of the latest alteration. Once completed, the responses need to be stored as CSV files for later forwarding to a reporting system. See the attached document for draft record layout. The required response is: a) The outsourcer's approach to the project, This should take up nomore than 1 to 2 pages. b) Definite cost and time for phase 1 based on these specifications. Also include hourly rates as it is envisaged the requirements will be fine tuned in cooperation with the outsource company once the initial iteration of clarification and response are completed. c) An indication of the range of cost and time for phase 2. 1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done. 2) Installation package that will install the software (in ready-to-run condition) on the platform(s) specified in this bid request. 3) Exclusive and complete copyrights to all work purchased. (No GPL, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the buyer on the site). ## Platform A C++ development for the P800 side is envisaged. If you propose otherwise, please state reasons. In the proof of concept phase, the main objective is to demonstrate the principle of generating forms on the fly on the P800 and using those forms to collect data. Sign-on module is not required. User will have already been authenticated. Communications module is not required. The data from completed user forms will be uploaded as separate files to the reporting system by the existing synchronization processes.