 | Back to APPENDIX D. SYSTEM MAINTENANCE |
 | Up to Appendix D Table of Contents |
 | Ahead to D.2 Perform Post-Implementation Review |
|
|
|
The maintenance process for implementation of corrective, adaptive, and perfective change requests is characterized by the following activities:
Table D-2 lists the activities performed and shows how the SDM development lifecycle phases (Initiate, Define, Design, Build, Evaluate, and Operate) may be correlated to system maintenance. While phases are combined for maintenance activities, they are performed in an iterative fashion depending on the size or scale of the maintenance effort.
|
Process Phase |
Process |
Process Products |
|---|---|---|
| Initiate | Change request initiation | Preliminary Maintenance Plan |
| Initiate | Change request identification, solution, and impact analysis | Feasibility Study, Risk Analysis, Maintenance Plan (updated) |
| Define, Design, and Build | Change request implementation | Security Plan; System Decision Paper; Functional Requirements Document; Data Requirements Document; System/Subsystem Specifications; Database Specifications. Program Specifications; Test Plans (unit & integration); Validation, Verification, & Test Plan |
| Build and Evaluate | Regression testing |
|
| Evaluate | Validation and verification | Test and Evaluation Report, Operations Manual, User's Manual, Installation and Conversion Plan, Training Plan and Training Guide |
| Evaluate | Solution acceptance | Tested and accepted product |
| Operate | Solution installation | Product installation in production environment |
Normally, system maintenance efforts are divided into the following three sizes:
Initiation of the maintenance process is the receipt of one or more software change requests (Needs Statement, ARN, or PTAR) for a system. In general, the requests should contain the problem or need for change, type of maintenance requested (corrective, perfective, or adaptive), and priority level. Assign a project development team to analyze requests. If a change request is a problem identified by a PTAR, determine if the problem is due to a misunderstanding of procedures or an actual processing malfunction. Also, determine if the problem is already being resolved in response to another PTAR. Provide a needs assessment, and generate a preliminary feasibility study for change requests.
Concurrently, the project manager defines a preliminary schedule, resource profile, WBS, and budget and documents the preliminary information in a maintenance plan.
This step localizes the change request to the precise parts of the affected software. Develop various change alternatives to satisfy the change request. Perform an impact analysis to evaluate the consequences to the system of each alternative, and select a solution. The project manager updates the maintenance plan to reflect the process activities and schedule, based on the scale of the effort to implement the solution.
The development team performs the unit modifications (design and code), generates unit and integration test plans, and performs unit and integration testing. Based on the scale of the effort, the development team updates the documentation specified in the maintenance plan. The acceptance test team updates the VV&T Plan with the new test procedures and expected results. QA monitors the implementation process for adherence to processes and standards.
The development team tests the new or modified components for compatibility with the existing system. Use the VV&T Plan that was generated during the development of the system. Choose the tests from the VV&T Plan that validate the functionality being modified by, or being affected by, the maintenance change. Use a test environment that duplicates the operational environment. CM configures the test environment.
This step is an independent verification and validation process that ensures the quality of the modified components. The acceptance test team, independent of the project development team, executes the new test procedures that validate the modifications and verifies that all of the change request requirements have been met. Additionally, the acceptance test team performs independent regression testing to verify that the maintenance change has not affected existing functionality. Use the original VV&T Plan to choose a limited set of regression tests. Document and forward any discrepancies to the maintainers for resolution. QA monitors test results and test plans. Make modifications to the User's Manual, Operations Manual, and Installation and Conversion Plan, as necessary. Check all modified documentation for conformity to requested changes.
The requester of the change performs solution acceptance. The requester checks the test results to verify that the solution fulfills and resolves the requested change. QA verifies that only authorized work was completed.
This is the step during which the modified software is placed into a staging area or is installed in the production environment. A production control unit normally replaces the old version with the new one.
Collect and analyze statistics for maintenance ARNs and PTARs. Focus the analysis on why a change was made, the type of change made (corrective, perfective, adaptive), and which areas were affected by the change. Reasons why a change was made could be a change in SBA regulations, hardware upgrade, support software upgrade, or new requirement on the system. Areas affected by a change could include the program, hardware, environment, database, data reports, documentation, and users. The data can be used to determine the impact on resources required to enhance the SBA system.
|
|
|
