Res 1994-016 - Laserfiche WebLink

Home Browse Search

S~If'- RIDER H - . -'. Schedule 3 MODULE FUNCTIONALITY TEST PURPOSE: The purpo~ of the Module Functionality Test is to verify that the required functional capabilities of the Software have ~n delivered. TIMING: Testing will coincide with the implementation of the various modules and shall occur during the training session for the module. For modules using tutorials instead of on site training, the test shall be completed or waived within sixty (60) days of installation. Training and testing will not occur until after the Hardware Functionality Test has Oeèn passèd and sufficient software and data have ~n loaded to permit training and the test to be effectively pèrformèd. Verification of the attached functional check lists will occur during the training ~ssions. THE CITY shall have an additional thirty (30) days to test additional functions related to the module(s) on which training was received. PERFOR1\ŒD BY: Library staff and DYNIX personnel. TEST t\ŒTHODOLOGY: (1) Prior to training. THE CITY shall designate one or more persons participatin~ in the training session who are authoriZèd to initial acceptance:: of the functional checklists attached. (2) During training THE CITY shall initial the functional checklist for features ob~rved and operational. (3) Functions which do not opèrate properly shall be noted and reported in writing to DYNIX. (4) THE CITY shall have thirty (30) days from the completion of training for a module to verify other functions which DYNIX documentation and the RFP Response indicates the Software will perform and submit any exœptions to DYNIX in writing. (5) DYNIX shall clarify and resolve all reported problems within thirty (30) days of receipt of report. Within seven (7) days of receipt of notice of resolution from pYNIX. THE CITY shall retest the function and confinn that the function has or has not bè.=n resolved. (6) DYNlX and THE CITY agree that not all aspects of the software are reasonably testable in the time frame given (e.g. "two-year cumulative statistics") and that certain aspects (e.g. "u~r friendliness") are subjective. Untestable features or aspects of the Software shall not prevent the Module Functionality Test from being accepted. ACCEPT ANCE: The Module Functionality Test for a given module will be successfully completed and THE CITY obligated to pay invoices as per Rider F when: (I) Each function of the appropriate functional checklist is operational. and CITY OF SA:-i MARCOS - PAGE R-19 January 17, 1994