Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 37
Implementation 37 Another aspect to be aware of as you develop your system is the versions of the other agency-wide systems that your system interacts with including the following: · Operating systems · Web-based browsers or Internet connection software · Runtime framework software · Database management systems · Geospatial software or tools Major upgrades or version rollouts can substantially affect your system functionality and design. Software Development Once you have defined your test procedures and versioning, you will start actual development. Development will consist of the following steps: 1. Develop the prototype. Prototype is the term for the system while it is being developed and before it has been officially accepted. 2. Prepare documentation. Documentation should start when development starts and should be updated throughout the development process. You should specify the type of documentation you require such as the user manual, a programmer manual, a data dictionary, on-line help, etc. and when it should be submitted such as with each milestone and test phase. Documentation is a part of the process that is often allowed to slide, which then results in limited usefulness if and when the software is completed. 3. Test prototype. Ideally, you want each potential user, or at least a representative of each use case, to test the system. Realistically, you will probably assign a small number of staff members from your office to perform the initial alpha test. It is important to document the results of the test based on the test plan to identify discrepancies between its performance and the design specifications as well as any problems or bugs. 4. Refine prototype. The prototype and documentation need to be revised to address the issues identified during alpha testing. As noted earlier, it is important to distinguish what is part of the original design that needs adjusting to meet the specifications and what is new or modified functionality. 5. Retest prototype. This is the beta test and is usually close to the deployable system. If possible, this testing should be as close to "live" as possible to make sure that it is performing as expected. 6. Implement system. Once you have officially accepted the system, you will roll it out to the right-of-way office staff. You may want to consider a phased implementation with one region going live followed by the remainder of the state or you can roll it out all at once. Training Plan As the system is getting ready for testing, you should prepare a training plan. This is separate from the regular training that will be necessary for new hires, although you can potentially use any material generated as part of the training process. You will need to consider the following aspects as you put together your plan. · Where will the training take place? Will you have one or more short courses at a central facility, will you visit the regions and/or local offices, or will you offer synchronous on-line training? · Will you offer training sessions for each type of user or will you train staff in the overall system? · Will you train trainers, training a selected number of staff members who then train the members in their area?