YLUPC
Phase3_clarifications – Yukon Planning Atlas

Phase3 Proposed Clarifications from Client

The following was in an email exchange to !JeffH about requirements for Phase3 on the signed contract:


Obviously, we anticipate best practices will be used in the development of code and adoption of data standards to ensure optimum performance and ease of maintenance, as amply demonstrated in previous projects by DMSG.

For greater comfort all around, I suggest the following clarification:

'Functional and Performance Testing' shall fall within the scope of 'Support installation of application at YLUPC', indicated as a task in Phase 3.

  1. Support installation/upgrade of application and component software , including Mapserver, PHP Mapscript, !PostgreSQL(w/PostGIS extension), Chameleon, including
    • support on 'build' issues for binaries built by YLUPC from source; or
    • provision of a binary FGS installation with all required modules; or
    • through direct access by DMSG application developer(s) to YLUPC servers using a secure shell connection (SSH) to perform builds.
  2. Provide advice as to 'optimal' configurations of software and data for 'best' performance, including
    • data compression (mod_gzip);
    • tiling of large data sets (shp files);
    • database indexing (Postgis data);
    • scale dependent layer definitions (MAP files);
    • data security (file permissions, user authentication)
  3. Demonstration of all features, widgets, hard and soft copy data outputs (Print and File Download), security measures, especially functional differences of non-registered users and site administrators. The Proponent (YLUPC) will sign-off on the production application only after all required functional elements, as identified and agreed to in Phase 1 ('a firm set of requirements') are production ready (stable).

YLUPC has not established any metrics for a minimum level of performance for this application. In Yukon, we are fortunate to have high-speed connections to all communities, and are among the best connected in Canada, however bandwidth restrictions from Yukon heading south do impinge on response time. As many factors can affect actual performance, we would suggest, as a general benchmark, that we attempt to avoid page load times in excess of 30secs. If performance for clients outside of Yukon is not possible within those parameters, we may consider other co-location options for our server/application.

Please let me know if the above clarification is satisfactory and acceptable, and confirm that it is 'within scope' of the original proposal.

jeffh

-- Main.JeffMcKenna? - 04 Dec 2006