Click for next page ( 42


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



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 41
The IT System LifecycleA Common Process 41 Table 3-4. Typical system availabilities. Ensuring that system documentation has been developed so that the system can be maintained and operated on an ongoing basis after it goes into service. These documents may include: User manuals. Operational manuals. Technical manuals. As-built drawings. Training manuals. System administration manuals. Configuration management plan. Developing the service level agreement. The SLA defines the performance of the system in App ways that are meaningful to the end user. It can serve as a contractual agreement between the end ix IT department and its service vendors or as an expectation of performance by the IT department A for its end users. Typical characteristics of an SLA include: System availability. How many minutes or hours the system was available divided by the total minutes in the period, expressed as a percentage. Examples of typical system availabil- ities are provided in Table 3-4. Response time for certain transactions, often measured in the 90th or 95th percentile. (e.g., "3 seconds or less in the 90th percentile" means that 90% of transactions had a response time of less than 3.0 seconds. The other 10% could have been very long.) Measuring system capacity or utilization against an agreed goal. Data throughput. Number of transactions. Accuracy of data. Responsiveness of the vendor. Number of active users. Number of trouble tickets. Mean time to repair (often confused with "mean time to respond," which does not include di- agnosis or repair). Table 3-5 provides a management project checklist for ensuring that all the necessary activities have been completed and the appropriate documents created during the implementation phase. 3.5 Operations and Maintenance Phase The term operations refers to the ongoing use of the installed system to provide benefits enumer- ated in the value proposition and project charter. The O&M phase consists of the system's day-to- day operations as well as predictive and preventive maintenance such as periodically replacing hardware, deploying personnel to maintain the system, and putting end-user support processes, such as the help desk, in place. Figure 3-6 shows the activities occurring during the O&M phase.

OCR for page 41
42 Information Technology Systems at AirportsA Primer Table 3-5. Implementation phase checklist. 3.5.1 Help Desk The help desk is the primary source of contact for users reporting technical malfunctions with a system. A service group for system users and administrators, the help desk leads and coordinates both in-house and external troubleshooting efforts. Problems are documented in the form of trouble tickets, which are tracked and acted upon until the problem is successfully resolved. Procedures and processes to be developed for help-desk support should include, at a minimum: Hours of help-desk operation and after-hours support process. End-user processes for notification of system failures. End-user processes for new service or changes to existing service. Internal processes for level 1 troubleshooting. Internal processes for escalating problems above level 1 support. Operations & Maintenance System Help Desk Administration Service Level Agreements (SLAs) Trouble System Documentation Tickets Performance Measures User Feedback Maintenance Change Request & New Requirements Figure 3-6. O&M phase.

OCR for page 41
The IT System LifecycleA Common Process 43 Trouble tickets are usually classified by type of issue, which determines the appropriate inter- nal or external resource to address the malfunction. Until the issue is resolved, the trouble ticket is left open and the problem remains in the work queue, with issues of higher priority taking precedence in the workflow. 3.5.2 System Administration System administrators handle day-to-day operations to keep the system operating effectively and smoothly for users. They take ownership of the system documentation developed at the end of the implementation phase and keep it up to date; they may also generate trouble tickets to correct malfunctions encountered in day-to-day operations. SLA enforcement is handled by system administrators, who collect system performance measure- ments in order to evaluate the system's ability to meet performance goals and SLA requirements. Performance measures established during system design are collected during the O&M phase to validate that system goals and user requirements are being met, enforce SLAs, and improve system and support methodologies. Performance measures must be objective and quantifiable. 3.5.3 User Feedback User feedback complements performance measures by capturing subjective aspects of the user experience to help signal emerging requirements, maintain user satisfaction, and address new needs as they evolve over the life of the system. A change request is developed once a system's performance and functionality diverge suffi- ciently from the original goals. The document should list the features that are absent from the current system and explain the forces motivating the change. A new requirement is developed to suggest the need for a major system upgrade, replacement, or new system. 3.5.4 Maintenance Ongoing maintenance is a critical component of meeting availability targets in the SLA. Main- tenance, performed by system administrators or the system vendor, consists of both preventive and reparative activities instigated by an issue documented in a trouble ticket. Preventive maintenance, a scheduled activity arranged to minimize its impact on operations, aims to prevent unplanned disruptions in service from hardware or software failures. Corrective maintenance, a response to unplanned system malfunctions, may lead to change requests when problems recur so that systemic problems can be fixed or system upgrades initiated. Table 3-6 provides a management project checklist for ensuring that necessary activities have been completed and that the appropriate documents from the operations and maintenance phase have been created. Table 3-6. O&M checklist.