Table of Contents | Chapter 10 | Chapter 12



11.0      OBJECTIVE

            11.1.1 Identify Systems Operations
            11.1.2 Maintain Data / Software Administration
            11.1.3 Identify Problem and Modification Process
            11.1.4 Maintain System / Software
            11.1.5 Revise Previous Documentation


            11.3.1 In-Process Review Report
            11.3.2 User Satisfaction Review Report



11.0     OBJECTIVE

More than half of the life cycle costs are attributed to the operations and maintenance of systems. In this phase, it is essential that all facets of operations and maintenance are performed. The system is being used and scrutinized to ensure that it meets the needs initially stated in the planning phase. Problems are detected and new needs arise. This may require modification to existing code, new code to be developed and/or hardware configuration changes. Providing user support is an ongoing activity. New users will require training and others will require training as well. The emphasis of this phase will be to ensure that the users needs are met and the system continues to perform as specified in the operational environment. Additionally, as operations and maintenance personnel monitor the current system they may become aware of better ways to improve the system and therefore make recommendations. Changes will be required to fix problems, possibly add features and make improvements to the system. This phase will continue as long as the system is in use.


11.1.1 Identify Systems Operations

Operations support is an integral part of the day to day operations of a system. In small systems, all or part of each task may be done by the same person. But in large systems, each function may be done by separate individuals or even separate areas. The Operations Manual is developed in previous SDLC phases. This documents defines tasks, activities and responsible parties and will need to be updated as changes occur. Systems operations activities and tasks need to be scheduled, on a recurring basis, to ensure that the production environment is fully functional and is performing as specified. The following is a checklist of systems operations key tasks and activities:

11.1.2  Maintain Data / Software Administration

Data / Software Administration is needed to ensure that input data and output data and data bases are correct and continually checked for accuracy and completeness. This includes insuring that any regularly scheduled jobs are submitted and completed correctly. Software and data bases should be maintained at (or near) the current maintenance level. The backup and recovery processes for data bases are normally different than the day-to-day DASD volume backups. The backup and recovery process of the data bases should be done as a Data / Software Administration task by a data administrator. A checklist of Data / Software Administration tasks and activities are:

11.1.3  Identify Problem and Modification Process

One fact of life with any system is that change is inevitable. Users need an avenue to suggest change and identified problems. A User Satisfaction Review (Appendix C-37 ) which can include a Customer Satisfaction Survey, can be designed and distributed to obtain feedback on operational systems to help determine if the systems are accurate and reliable. Systems administrators and operators need to be able to make recommendations for upgrade of hardware, architecture and streamlining processes. For small in-house systems, modification requests can be handled by an in-house process. For large integrated systems, modification requests may be addressed in the Requirements document and may take the form of a change package or a formal Change Implementation Notice (Appendix C-32) and may require justification and cost benefits analysis for approval by a review board. The Requirements document for the project may call for a modification cut-off and rollout of the system as a first version and all subsequent changes addressed as a new or enhanced version of the system. A request for modifications to a system may also generate a new project and require a new project initiation plan.

11.1.4  Maintain System / Software

Daily operations of the system /software may necessitate that maintenance personnel identify potential modifications needed to ensure that the system continues to operate as intended and produces quality data. Daily maintenance activities for the system, takes place to ensure that any previously undetected errors are fixed. Maintenance personnel may determine that modifications to the system and databases are needed to resolve errors or performance problems. Also modifications may be needed to provide new capabilities or to take advantage of hardware upgrades or new releases of system software and application software used to operate the system. New capabilities may take the form of routine maintenance or may constitute enhancements to the system or database as a response to user requests for new/improved capabilities. New capabilities needs may begin a new problem modification process described above.

11.1.5  Revise Previous Documentation

At this phase of the SDLC all security activities have been completed. An update must be made to the System Security plan; an update and test of the contingency plan should be completed. Continuous vigilance should be given to virus and intruder detection. The Project Manager must be sure that security operating procedures are kept updated accordingly. Review and update documentation from the previous phases. In particular, the Operations Manual, SBD and Contingency Plan need to be updated and finalized during the Operations and Maintenance Phase.


This list briefly outlines some of the roles and responsibilities for key maintenance personnel. Some roles may be combined or eliminated depending upon the size of the system to be maintained. Each system will dictate the necessity for the roles listed below.


11.3.1  In-Process Review Report

The In-Process Review (IPR) occurs at predetermined milestones usually quarterly, but at least once a year. The performance measures should be reviewed along with the health of the system. Performance measures should be measured against the baseline measures. Ad hoc reviews should be called when deemed necessary by either party. Document the results of this review in the IPR Report. Appendix C-35 provides a template for the IPR Report.

11.3.2  User Satisfaction Review Report

User Satisfaction Reviews can be used as a tool to determine the current user satisfaction with the performance capabilities of an existing application or initiate a proposal for a new system. This review can be used as input to the IPR Report. Appendix C-36 provides a template for the User Satisfaction Review Report.


11.4.1 Documentation 

It can not be stressed enough, that proper documentation for the duties performed by each individual responsible for system maintenance and operation should be up-to-date. For smooth day to day operations of any system, as well as disaster recovery, each individuals role, duties and responsibilities should be outlined in detail. A systems administrators journal or log of changes performed to the system software or hardware is invaluable in times of emergencies. Operations manuals, journals or logs should be readily accessible by maintenance personnel.

11.4.2 Guidelines in determining New Development from Maintenance

Changes to the system should meet the following criteria in order for the change or modification request to be categorized as Maintenance; otherwise it should be considered as New Development :

11.4.3  Security Re-certification

Federal IT security policy requires all IT systems to be accredited prior to being placed into operation and at least every three years thereafter, or prior to implementation of a significant change.


Review activities occur several times throughout this phase. Each time the system is reviewed, one of three of the following decisions will be made:

The In-Process Review shall be performed to evaluate system performance, user satisfaction with the system, adaptability to changing business needs, and new technologies that might improve the system. This review is diagnostic in nature and can trigger a project to re-enter a previous SDLC phase. Any major system modifications needed after the system has been implemented will follow the SDLC process from planning through implementation.

Table of Contents | Chapter 10 | Chapter 12