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?
