11th Chapter-System Maintenance

The rules of software engineering suggest that systems develop early changes in maintenance. If you have organized the design code module and the cross-references section in the requirements phase, you can track requirements changes to the affected modules and must be re-tested. Accordingly, if an error occurs, you can find the module that contains the error, and then make corrections on all levels (design, coding, and testing), not just on the encoding. The principle of software engineering not only leads to good design and code, but also leads to rapid change ability.

When we develop a system, we focus on generating code that can fulfill the requirements and work properly. During each period of development, we continue to draw on the results from the pre-and post-phase. The system design is closely linked to the requirements specification, and the code modules are cross-referenced. and consistent with the design, the tests are based on the requirements and design of the functions and specifications that were found. Therefore, development involves a careful and controllable review of the system. Maintenance is different, as maintenance personnel, we not only review the development of products and establish the relationship between users and operators. To find out whether they are satisfied with the way the system works, we look to the future to see what will go wrong in advance. Consider the functional changes due to changing business requirements and consider the need to change the system due to changes in hardware software or interfaces. Therefore, the scope of maintenance is broader. There are more things that need to be traced and controlled. Let's take a look at the activities that need to be performed to make the system work smoothly and to differentiate between the operators.

The traditional software life cycle describes maintenance as having been started after the software has been put into use. However, the maintenance of the software depends on and begins with the user's needs. Therefore, good software development rules will be used for development and maintenance processes. Because good software development supports software changes, change is a problem that must be considered during the life cycle of a software product. And a seemingly unimportant change is often more extensive than expected. Impact analysis is an assessment of the risks that many changes may generate, including the impact on resources, workload, and work plans. The effects of changes in multiple parts can be found in inappropriate and outdated documents, such as inappropriate or incomplete patching, design or coding of unclear structures, non-conformance to standards of self-made items, etc. The problem is compounded by the increase in complexity, the increase in developer understanding of the time required to change the code, and the increased negative impact of code changes on other parts of the system. These problems add to the overhead of maintenance, and management tends to make this overhead easy to control. We can use impact analysis to control maintenance overhead.

11th Chapter-System Maintenance