Laserfiche WebLink
PROJECT APPROACH <br />1. Discovery -Define needs, requirements, and use .cases, in order to understand user <br />expectations. For example, -the kickoff meeting and user needs assessment tasks provide a <br />group forum for discovery. Email and phone exchanges will also be utilized. <br />2. Design - Develop a design for the system framework, including the map server and web <br />browser application, and for each component based on the system requirements. The level of <br />interaction with the State on design aspects will vary by component. For example, the <br />selection of the framework for the Flood DSS will require that State IT/GIS staff understand <br />key aspects of the design in order to agree with technology recommendations. However, the <br />design for specific components may have limited options due to the use of existing <br />components (e.g., Laserfiche). <br />3. Development and Testing -Development of the system framework and specific <br />components will occur based on the design. In an agile approach, the development team <br />provides releases of the system on an approximately two to four week interval. Each release <br />seeks to quickly resolve issues in the previous release, while introducing new components. <br />4. Review - In an agile approach, users are provided the opportunity to evaluate the system and <br />provide feedback. This feedback is then considered in the next iteration of development in <br />order to address system limitations while remaining in the overall scope. <br />5. Training and Deployment -Training will be provided as major parts of the system are <br />deployed to the State's system and will consist of information for system administrators and <br />users. <br />In some cases, the tasks will be performed in parallel using the above methodology. For <br />example, the kickoff meeting may identify requirements for all components whereas design and <br />development can occur independently for various system components. The design and <br />configuration of some components may be revisited as data collection occurs (e.g., to adjust <br />implementation of a tool based on the attributes that are available in a data layer). The technical <br />specifications in the RFP do not require an agile development process, but specific activities <br />(e.g., the kickoff meeting, training) fit naturally within the framework. <br />The agile process involves .assigning priority to activities, both to guide development effort and <br />to identify risk areas.. State involvement in reviewing activities and assigning priorities will <br />allow Riverside to identify whether an activity is in scope (i.e., priority 1) or is a potential Phase <br />II item (i.e., priority 3). <br />Deliverables <br />1. Flood DSS website, with data and additional features added in later tasks. <br />4.4 Data Inventory <br />Goals <br />Identify the data types that will be included in the Phase I Flood DSS, taking into account user <br />needs, data availability, integration effort, and project resources. <br />I, Background <br />In 2006, Riverside developed the Flood DSS prototype focusing on Larimer County. The <br />prototype system included a number of data layers that. were available at spatial extents varying <br />from local to statewide (Table 4-1). Most of the statewide data were available from the CWCB, <br />DWR, federal agencies, or the CDSS. County and local data were obtained by contacting city <br />DNR RFP PDA-923 33 R ~ V E R S ~ D E <br />