15.1. Organization and methods of software maintenance

During the operation of software versions, each user may have some complaints about the functioning, which they qualify as errors or defects of the reference (basic) or own version. Proposals on making changes to the basic version to improve the operational characteristics and expand the functional capabilities of the system and the program complex may also come from users or the customer. Similar proposals may come from the developers of PS. In order to communicate with users and accumulate information on detected deficiencies in replicable complex software systems, it is advisable to select a group of highly qualified specialists who have mastered all the functions of the system and the software product.

When organizing the maintenance of major substations, important psychological factors should be taken into account , complicating the involvement and activities of managers and qualified specialists in this field:

• this activity requires very high qualifications and high mental costs associated primarily with the need for simultaneous, wide coverage and analysis of many PS components and their interrelations that are in different states of completion of modifications;

• adjustable components have often been developed in the past at different times, by different specialists, in different styles and with different

461

Lecture 15. Maintenance and monitoring of software

the naked completeness of documentation, which complicates the development of their content when making changes and eliminating defects;

• the complicated, creative side of work when accompanied is veiled by the fact that it is necessary to master and analyze programs developed earlier by other specialists, which often, perhaps, it is easier not to correct, but to develop anew;

• complex programs that have undergone extensive testing and operation with customers guarantee the achieved quality of operating results, and any changes to them have a high risk of introducing additional errors and deterioration of this quality, which limits the possibility of radical modifications;

• the work performed requires a special, coordinated thoroughness of adjustments and a well-defined, regulated interaction of a number of specialists with different qualifications and levels of responsibility;

• the processes and the results of the maintenance are not distinguished by their visibility and external effect, the manifestation of their size and complexity, as a result of which they are not prestigious among ordinary programmers and underestimated by the project managers.

With the development of the use of complex software products, it became clear that the integral costs of maintaining and creating new versions may significantly exceed the costs of developing their first version. The experience of recent years has shown that in many cases, the same or more specialists are needed to maintain and monitor versions than developed the first version of the software. When creating complex PSs, the transfer of specialists from the development of new software components and PSs to the development and maintenance of versions is systematic. This leads to the fact that with the accumulation of operating substations and their components, an increasing number of specialists are moving from the area of ​​direct programming of new programs to the area of ​​system design and creating new versions of substations based on reusable components.

Only after completing the creation of several PS versions can the transition of additional personnel to the area of ​​maintenance and configuration management cease and a stable ratio between the number of specialists engaged in the initial development of new projects and

462

15.1. Organization and methods of software maintenance

accompanying versions of PS. Very often, the developers of the new software do not envisage this process and the required resources, which significantly reduces the effectiveness of the subsequent use of the created software product. According to some estimates, about 15–20% of the professionals involved in the creation of software products are directly programming in the world.

The purpose of maintenance is to identify and eliminate detected defects and errors in programs and data, introduce new functions and components in software systems, analyze the status and correct documentation, replicate and control the distribution of software versions, update and ensure the safety of documentation and physical media - fig. 15.1. The main task is to change and improve the existing software product, while maintaining its integrity and functional suitability. To preserve and improve the quality of complex software packages, it is necessary to regulate the processes of modifying and improving software tools, as well as to support them with appropriate testing and quality control.

The widespread use of prototyping and reuse of ready-tested software components contributed to the transformation of support into a special section of methods and tools to ensure the PS life cycle. The maintenance technology should provide for the coordinated development of multiple versions of software systems and their components, each of which has a sufficiently high quality and specific functions, as well as, possibly, different users. Due to this, over time, the software should be improved and improved both in functionality and in the quality of the solution of each task.

Accompanying - the possibility of a regulated modification - is an important characteristic of the PS for customers, suppliers and users, reflecting the possibility and ease of making changes to the software product after its commissioning. Maintenance requirements should be included in the preparation during the ordering process, and their implementation should be assessed in the process of developing PS modifications. Various indicators can be used to determine and assess the quality of the modified software.

463

Lecture 15. Maintenance and monitoring of software

qualitative and quantitative standardized metrics in accordance with ISO 9126.

Objectives and composition of software maintenance processes

Causes and types of software changes when accompanied

Organization of processes and transfer to software maintenance

Conclusion of a contract between the customer and the contractor for the maintenance of the software

Development of the concept of methods and processes of software product support

Development of specification requirements for software modifications

Evaluation and distribution of resources, finances and specialists for software product support

Development of requirements for quality assurance in the maintenance of a software product

Approval by the customer of the concept, contract and technical specifications for the maintenance of a software product

Organization of control over the implementation of the concept and contract for software product support

Fig. 15.1

The maintainability must be determined before the start of the initial development of the PS project by an appropriate agreement between the customer and the developer-supplier. The developer must prepare a maintenance plan that outlines specific methods, related resources and work sequences. It should be

464

15.1. Organization and methods of software maintenance

Make the necessary effort to ensure the monitoring and evaluation of aspects of maintainability during the development process. Requirements for maintenance processes are determined by a group of key factors affecting the implementation of software modifications that form a conceptual chain: requirements for changes - changeable functions - size (scale) of changes - strategy of modifications - resources necessary for their implementation. This logic is usually used in the sequential analysis of the processes of maintenance of complex PS. In this case, the main criterion for evaluating maintenance is the improvement of functional suitability and improvement of the quality characteristics of a software product.

The main process of operation in the life cycle can initiate the process of maintenance of the PS by submitting proposals for modification (change) or reports on defects. The software maintenance process in accordance with ISO 12207 (clause 5.5) and the specification of this section in ISO 14764 uses the basic standardized process of developing software packages and supporting documentation, configuration management, quality assurance, verification, certification, elimination of defects. Organizational management, infrastructure, and training processes should be determined by the facilitator at the beginning of each maintenance project.

The cost of the maintenance process can be a significant (even the largest) part of the life cycle cost of a software product. The period of significant changes in the size, functions and quality characteristics in large projects of program complexes is usually 1-2 years. As a result of the research, the concept of “critical complexity and size expansion” of the modified part of the PS version appeared while being accompanied. If during upgrades and the release of a regular version, the size of the improvements significantly exceeds the “critical”, then there is a high probability of partial deterioration of system characteristics or the need to release several intermediate versions to eliminate errors in changes and achieve high quality upgrades.

Characteristics describing the qualitative and quantitative requirements for the maintenance of the software, set by the customer. When implementing the processes of development, operation and maintenance of

465

Lecture 15. Maintenance and monitoring of software

Any defects found should be described and monitored through the processes recommended in ISO 14476. In this case, appropriate proposals for modifications or reports on identified defects should be prepared. In this process, it is also determined whether the presented defects affect the need for upgrading the software product. The configuration management (CM) process records and documents the status of modification proposals or defect reports.

The customer may enter into an agreement with the developer of the base version of the PS regarding the organization of the support or select a third party (other than the developer) as an accompanying person (see Figure 15.1). Maintenance can also be carried out by agreement between two parties within the same enterprise. These provisions should be used regardless of whether the customer or supplier belongs to the same or to different enterprises.

The transfer of software for maintenance is a controlled and coordinated sequence of actions, during which the developed product passes from the enterprise that completed its initial development to the specialists or enterprise that accompanies its maintenance. In the process of transfer should be reflected:

• requirements for the transfer of hardware and software, data and knowledge (experience) from developer to maintainer;

• Accompanying tasks required for the implementation of a software product maintenance strategy: staffing, training, introducing software versions, distributing maintenance experience.

Accompanied sometimes meet the need to accompany the software product with a minimum set of documents or even in the absence of them. In the absence of the necessary documents, the maintainer must create them, which is a mandatory part of the full correct maintenance. In such a situation, the companion in preparation for the maintenance should:

• identify the problem area (type of software product);

• examine any available documents, discuss the software product with the developers, if possible, and work with this product;

466

15.1. Organization and methods of software maintenance

• study the structure and organization of the software product;

• inventory it, subject the product to configuration management, build the product in accordance with the configuration management libraries, create scripts and call trees, and analyze the structure of this product;

• define the functions implemented by the software product; if possible, review technical requirements (specifications) for this product, its general structure, analyze call trees, read program codes, provide this product to other maintainers and comment on program codes;

• prioritize modification proposals.

The maintainers should document the software product in accordance with the recommendations given. The following documents should be updated or developed (if necessary): technical requirements (specifications), maintenance specialist manuals, user manuals, and commissioning and installation manuals.

The maintainer and the customer must conclude a contract for maintenance and indicate in it possible procedures for introducing changes to the accompanying software products (see Fig. 15.1). Procedures can be used as the developer of the original, the basic version of the PS, and an independent maintainer and cover '.

• the basic requirements and rules used to determine when the PS can be locally adjusted, and when a new basic version of the software product is needed using it to prepare and install the development process;

• descriptions of types of revisions of versions, depending on the frequency of their appearance or the impact on the operation of the software product (for example, emergency editions, periodical editions);

• Ways to inform the customer about the current or planned changes;

• methods confirming the impossibility of additional problems and defects in connection with making specific changes to this software;

• classification of the type of change, its sequence (priority) and the relationship with other proposed changes.

467

Lecture 15. Maintenance and monitoring of software

To implement the changes, the main process of developing PS and its components should be planned and used, the requirements for which are supplemented by: established and documented criteria for testing modifications, evaluating their results, as well as evaluating modified and unchanged objects (software modules, components and configuration elements); as well as the completeness and correctness of the implementation of new and modified requirements, so that the original, unchanged requirements for the software product are not distorted.

Support personnel must verify the changes made together with the customer who approved the modification in order to confirm the functional suitability and operability of the corrected software product, and receive confirmation that the change made meets the requirements specified in the contract.

The specification of requirements for software changes should exhaustively and unambiguously describe the mandatory requirements for the software and its modifications and reflect the quality characteristics required by the standards. In this case, the following factors affecting the maintenance should be taken into account :

• definition and description of new features;

• accuracy and logical organization of data;

• interfaces (system, components and users), especially new and promising interfaces;

• requirements for functions and performance, including the effects of adjustments and additions;

• requirements imposed by the planned external environment;

• quality assurance plan for the modified software product, in which special attention should be paid to the documents for changes and their consistency.

It is advisable to start the development of the maintenance concept with the formalization and justification of a set of input data reflecting the general features of the class, the purpose and function of the PS, the consumers and the stages of the project life cycle, each of which influences the choice of certain characteristics of the program complex change (see Figure 15.1). To do this, it is initially advisable to use the software classification according to ISO 12182 and the entire basic nomenclature

468

15.1. Organization and methods of software maintenance

functional characteristics and quality standardized in ISO 9126. It is desirable to pre-order their descriptions in order of priorities, taking into account the specifics of the purpose, the scope of modifications and the application of a particular PS.

At the stage of creating the concept and system analysis, it is necessary to formulate maintenance goals, select methods and algorithms for modifying basic, functional tasks, as well as formulate preliminary criteria for the quality of new software components and data being created. This, of course, raises the question of the resources that will be needed to achieve these goals, and the possibility of their realization. Purposeful and methodical expert assessment of the possible scale and resources for changes reduces the magnitude of errors, but usually it remains quite large. To ensure rational reliability, it is advisable to carry out primary prediction by extrapolation on the basis of accumulated specific data on certain similar modifications of PS.

Until the development of a new basic version of the software product is completed, only approximate initial requirements can be formulated , reflecting the objects of modifications and the conditions for their creation. Nevertheless, an expert survey of leading experts allows you to create a primary scenario of the scale and conditions of the next modification of PS. Even a qualitative classification and description of the characteristics of change scenarios significantly improves the accuracy of the forecasts of requirements specifications.

In the escort concept, the customer and development specialists must submit requirements, document the plans and procedures for carrying out the work and the implementation of the tasks of this process. They should define procedures for receiving, documenting and monitoring defect reports and change requests from users, as well as providing feedback to users. Whenever problems (defects) arise, they must be documented and entered into the solution process. For analysis and elimination, they should implement the process of managing changes and configuration of an existing PS and determine organizational procedures for interacting with this process. It is necessary to analyze the report on defects and requests for amendments on their impact on

469

Lecture 15. Maintenance and monitoring of software

organizational processes, the existing system and interface connections with other systems and establish:

- adjustment, modernization, prevention or adaptation to new conditions;

• size of change, cost, time to implement the change;

• criticality, impact on basic functions, performance, safety or protection.

Based on the analysis performed, the support staff should develop options for the implementation of the change processes and document: a message about the defect or an application for modification; results of their analysis and requirements for the implementation of changes. It is necessary to coordinate with the customer the selected options for changes in accordance with the contract. The maintainer must analyze and determine which documents, software modules, components, or their versions need to be changed. The results must be documented.

A description of the escort concept should be the first step in developing a PS escort policy. It should be developed at the first release of the original software product and reflect:

• area of ​​maintenance of the product;

• practical application (adaptation) of this process;

• identification of the company and persons responsible for maintenance;

• assessment of the cost and duration of maintenance.

The maintenance area should define the responsibilities of the maintainer and what support he should provide to the software product. It is often determined by the availability of appropriate resource and budgetary constraints and should cover:

• types of allowable changes and maintenance procedures;

• quality level of the accompanying documents;

• reaction (sensitivity) of users to maintenance;

• provided level of training for escort personnel;

• ensuring the delivery of modified versions of the software product;

- the possibility of organizing a referral service - "hot line". The concept should not take into account software maintenance tasks.

product after delivery. By important part of of An escort the concept is to the identify resources and Specialists (Physical or legal-).

470

15.1. Organization and methods of software maintenance

ies) responsible for product maintenance. This is the case for internal support within the organization. It is noted in the escort concept. The choice of factors should be based on a number of factors:

• service life of the software;

• the size of the primary and long-term maintenance costs;

• the qualifications of the accompanying staff;

• functional suitability and performance of the original, basic version of the software product;

• program (schedule) of modifications and maintenance;

• knowledge by the maintainer of the software application domain.

The conditions of financing and the cost of maintenance should be assessed. The cost depends on the size of the escort area. Additional factors to be taken into account are the cost of: training for both maintainers and users; Environments of software tools, testing and their annual maintenance. When developing a maintenance concept, the cost is estimated based on limited input data. In the future, these estimates should be clarified.

It is advisable to carry out the development and approval in the concept of specifications of requirements for the functional characteristics and quality of a software product , taking into account the changes made, iteratively. Full and one-time formalization of the requirements for the characteristics of each major modification at the beginning of the PS life cycle is usually impossible, first of all, due to different ideas of the customer and developers about the details of its purpose, functions and implementation possibilities with the available resources. The larger and more complex the PS project and, accordingly, the higher its cost, the more carefully it is necessary to develop requirements for its maintenance characteristics and allocate resources for their implementation.

When initially defining the requirements for functional suitability and for design characteristics, resource constraints specified by the customer may not always take into account a number of features of the project support, which will result in an unacceptable reduction (or overestimation).

471

Lecture 15. Maintenance and monitoring of software

requirements) for some characteristics of the modified PS. In addition, it is possible that some of the characteristics or their changes are contradictory or fundamentally impossible to implement in this project. As a result, unbalanced requirements and available resources will manifest as losses in quality or in the need for additional resources.

Depending on the complexity of the project, the final result of the work in forecasting changes to the program complex should be detailed and approved requirements for the nomenclature, properties and quality values ​​of the software product, which are sufficient for its full-fledged maintenance and subsequent effective operation. These requirements are enshrined in the concept, contract and terms of reference,for which the maintainer must subsequently report to the customer upon completion of the modifications. However, at subsequent stages of the life cycle and during configuration management, requirements may change by agreement between the customer and the developer, which are often timed to coincide with the preparation of a new basic version of PS. This requires monitoring of the functional suitability, scale of the project, requirements and implementations of characteristics throughout the life cycle of the substation.

Fundamental and technical capabilities, accuracy of the implementation of the properties and measurement values ​​of the characteristics of the PS, as well as the overall resources of a particular project are always limited in accordance with their content and the capabilities of the customer and developers. This determines the rational ranges of the values ​​of each change, which can be selected in the concept of maintenance of PS based on customer requirements, common sense, as well as by analyzing the pilot projects and precedents in the specifications of the requirements of the implemented modifications. With limited resources of a large PS project, the distribution of priorities should become more stringent and the priorities of changes in characteristics, for the implementation of which resources are insufficient, may decrease. As a result, a completea set of required functional and structural characteristics of quality in the process of maintenance of PS.

Requirements for functional characteristics and quality, approved after the design of the concept, can be fixed in the technical task as mandatory for the detailed and detailed design.

472

15.2. Stages and procedures in software maintenance

modifications of modifications (see fig. 15.1). These data can be used in the subsequent quality assessment and in their comparison with the requirements in the process of qualification tests, certification modifications or a new basic version of the software product.

For the to customer and the users, the when Accompanying, IT may the BE by important not only to the Determine the functional suitability, But Also to ASSESS the Potential 'demand in the market for a Particular software product product, as with the a well as with the ITS Competitiveness with OTHER advertisers Select Similar software functions The, taking Into account its quality and cost. It was not necessary to follow the circumstances.

15.2. Stages and procedures in software maintenance

In accordance with the requirements of ISO 12207 for the development and modification of a software product in the life cycle , the process of its maintenance should be organized (see clause 5.5). Works that provide support for PS include:

• process preparation;

• analysis of problems and changes;

• alteration;

• check and acceptance when accompanied;

• transfer;

• decommissioning.

These sections and the corresponding processes are detailed in ISO 14764 and are commented below with a number of comments. After activating the process, a maintenance plan and appropriate procedures should be developed, and specific resources should be allocated for maintenance. After the software product has been delivered to the customer, the maintainer, in accordance with the contract and modification proposal or defect report, shall change the relevant programs and documents. Baseline data is converted or used in maintenance work.

473

Lecture 15. Maintenance and monitoring of software

for output - modified versions of the software product. It is recommended to conduct regular monitoring in order to verify the correctness of the output results of specific maintenance work.

Preparation of processes and specifications of requirements for maintenance of I software I

I

I Defining a software maintenance strategy

Develop a plan for milestones and maintenance procedures

software tool

'

Analysis of detected defects and suggestions for modifications

to adjust the software

I

Identifying change implementation and monitoring processes

software tool

Joint analysis with the customer and approval of software version revisions

i

Qualification testing, acceptance of adjustments

and confirmation of the satisfaction of the contract requirements

on software product support

i -

Documenting modifications, process and outcome reports

software support

I

Implementation for the use and operation of the new basic version

software product

Educating users to use the new basic version of software

product

Decommissioning, archiving and termination of software version maintenance

Fig. 15.2

When preparing the process, the maintainer must create plans and define the procedures to be performed during the implementation of the maintenance (Fig. 15.2). It is advisable to create a maintenance plan in parallel with the development plan for the first, base version of the software. When performing this work

474

15.2. Stages and procedures in software maintenance

The maintainer bots must also be defined. The initial data of the software product; system documents; modification proposals and defect reports. Ensure the effective To implementation of the escort process, the maintainer should develop and document a escort strategy, one of the key factors in the development and application of the PS. When implementing this plan, the maintainer must: develop plans and procedures for maintenance; establish procedures for reviewing proposals for modifications and defect reports; apply configuration management.

The maintainer must develop, document and execute plans and procedures for carrying out the work and solving the tasks of the support process. The maintenance plan should describe the system maintenance strategy, and the maintenance procedures should define the details of the steps and the maintenance processes. To ensure the creation of effective maintenance plans and procedures, the companion should:

• evaluate the system being followed;

• guarantee official confirmation of assuming the responsibilities of the maintainer of the software product;

• analyze available resources for maintenance;

• evaluate and agree with the customer financing and maintenance costs;

• establish requirements for the process of transferring the software product to the maintainer;

• determine the maintenance processes to be implemented;

• document the maintenance process in the form of plans and procedures agreed with the customer.

The maintenance strategy should be focused on the human and material resources necessary and accessible to ensure the development and modification of the software product. The maintenance policy of the PS should cover the following main components: the maintenance concept; maintenance plan; resource analysis. The process of developing changes includes a number of activities related to planning

475

Lecture 15. Maintenance and monitoring of software

driving the PS. These types of activities should be defined in the software product maintenance strategy: a threshold value in terms of value is defined, allowing to make a corresponding change in PS without revising a specific contract with the customer; interface agreements for the entire project in terms of persistent problems related to ambiguity, inaccuracy, variability or unverifiability of customer requirements and specifications.

The purpose of maintenance planning is to prepare a maintenance work plan and provide the resources necessary to carry out these activities after the software is transferred for maintenance. Planning begins after defining the PS maintenance concept and ends with the development of a maintenance plan used as a basis for maintenance. The overall maintenance plan should determine:

• reasons for the need for maintenance;

• the list of performers of works on support;

• the roles and responsibilities of each subject involved in the accompaniment;

• how the main processes and work should be performed;

• what resources are available and necessary for maintenance;

• methods and means of organizing work on the management, product release and work synchronization;

• a list of all project results and products to be delivered to the customer;

• criteria for the completion of relevant activities, work and tasks;

• the composition of the reporting materials on the stages, costs and schedules of work;

• frequency and methods of issuing reporting materials;

• the composition of the reporting materials on problems and eliminated defects;

- the start time and the duration of the accompaniment. It is recommended that escorts formalize a specific plan.

maintenance of substations from the general composition of life cycle processes that is specified and adapted to the scope and features of the project, containing sections:

476

15.2. Stages and procedures in software maintenance

• description of the accompanying system, which includes PS;

• concept of support of a complex of programs; description of the system maintenance level and PS; setting the duration of the maintenance processes; adaptation of standardized maintenance processes;

• organizational support work, roles and responsibilities of specialists;

• resources: composition of specialists; tools; technical means; documents and plans;

• processes - how specific activities should be performed;

• determining the level of training required for maintainers and users;

- protocols and maintenance reports; control data collected during maintenance work.

Architecture design modifications defines the functions and components of the modified software. The main features of this work among the life cycle processes of the PS that affect the maintainability are the choice of the program structure, its splitting into components (modules) and the data flow circulating between them. When modifying, it is important to use the knowledge of the data processing team related to the possibility of using parts of existing programs or libraries that have proven high functional quality. The main tools to help ensure maintainability requirements are a modular architecture, combined with top-down analysis and relevant documents, which can be supplemented, if necessary.

When designing the software, versions of each component of the software, interfaces and databases are created. Accurate, detailed descriptions of each function are made to implement the proposed changes. Software maintainability can be improved by taking into account the quality characteristics specified in ISO 9126. The maintainer should define the procedures for: receiving, documenting and monitoring defect reports and suggestions for modifications from users; provide user feedback. Each emerging problem and defect must be documented and entered into the process of analyzing changes, for which follows:

477

Lecture 15. Maintenance and monitoring of software

• develop a classification and prioritization scheme for proposed modifications and defect descriptions;

• develop procedures for conducting targeted analysis of changes;

• define procedures for the presentation of proposed modifications and descriptions of defects by the operator;

• determine the organization of user feedback when analyzing changes;

• determine how users will be served during the implementation of maintenance;

• Determine how the proposed modifications will be entered into the database for accounting for change conditions and resources used.

The analysis of defects and modifications in the ISO 14764 standard is recommended to be implemented in the following order:

• modifying suggestions and defect reports;

• the reality of each defect is duplicated or verified;

• options for implementing change are being developed;

• Documented are: the proposals for modifications and reports on defects, the results of their consideration and the options for implementing the changes;

• coordination of the chosen variant of implementation of the change with the customer is carried out.

Before making changes to the system and PS, the accompanying person must: analyze possible changes in terms of their impact on the activities of the enterprise, the existing system and its interconnected systems; develop and document recommended alternative solutions for making adjustments and coordinate the decision to make changes with the customer. The maintainer needs to analyze a problem report — a defect or a proposal for a modification on their impact on organizational issues, the existing system, and interface connections with other systems by type: adjustment, modernization, prevention, or adaptation to new conditions or environments; scale: change size, cost, time to implement the change; by severity: impact on performance and performance, safety or product protection.

To ensure the implementation of the submitted change proposal, the maintainer must determine:

478

15.2. Stages and procedures in software maintenance

• the availability of appropriate personnel capable of implementing the proposed change;

• the availability of sufficient funding to implement the proposed change in the program;

• the availability of appropriate computer resources and the degree of influence of modifications on the implemented or already implemented versions of the software product;

• whether the absence of anticipated changes affects the requirements for system interfaces, the expected service life of the system, priorities;

• the impact of changes on the safety and security of the system during operation;

• non-recurring and long-term adjustment costs;

• benefits obtained after the modification;

• the impact of the implementation of changes on the work schedules of the software version;

• the necessary processes of verification, testing and evaluation of the characteristics of the system and software product after making adjustments.

In order to confirm the relevance of the submitted defect reports, the maintainer must duplicate and verify the problems that have arisen — the defects — by completing the following steps to solve this problem: develop a verification and qualification testing strategy to verify the elimination of a specific problem — the defect; conduct testing to check for the presence of a problem - a defect; to document the results of qualification testing. If a specific problem cannot be repeated by the maintainer, he should check the rules, policies and documents of the life cycle maintenance of the substation in the enterprise. Based on the analysis performed, the maintainer should develop options for implementing the change:

• assign the appropriate priority to the problem (defect) or proposal for modification;

• establish the availability of facilities and means to solve the problem;

• to assess the scale and complexity of this modification;

• develop options for implementing a specific change;

479

Lecture 15. Maintenance and monitoring of software

• determine the impact of these options on the functional suitability and technical means of the system;

• perform risk analyzes for each modification option.

The maintainer must implement a configuration management process for managing changes to an existing system or define an organizational interface with this process (see Chapter 16). The results of this work are: the plan and procedures for maintenance; procedures for solving problems and eliminating defects; user feedback plans; plan for transferring modifications to the customer and users. Before making changes to the system and software product in accordance with the contract with the customer, the maintainer must agree on the chosen correction option.

Monitoring of the work in question should be carried out through a joint revie