Lecture
In the course of operating versions of a software product, each user may develop certain complaints about its functioning, which they classify as errors or defects of the reference (baseline) or their own version. Users or the customer may also submit proposals for making changes to the baseline version in order to improve operational characteristics and extend the functional capabilities of the system and the software suite. Similar proposals may come from the developers of the software system. To communicate with users and accumulate information on the shortcomings identified in widely distributed, complex software systems, it is advisable to set up a group of highly qualified specialists who have mastered all the functions of the system and the software product.
When organizing the maintenance of large software systems, it is necessary to take into account important psychological factors that complicate the recruitment and work of managers and qualified specialists in this field:
this activity requires very high qualifications and considerable mental effort, associated above all with the need for simultaneous, broad coverage and analysis of numerous software system components and their interrelations, which are in various states of completion of modification;
the components being corrected were often developed in the past at different times, by different specialists, in different styles and with varying completeness of documentation, which complicates mastering their content when introducing changes and eliminating defects;
the complex, creative side of maintenance work is obscured by the fact that one has to master and analyze programs developed earlier by other specialists, which it is often, perhaps, simpler to rewrite from scratch than to correct;
software suites that have undergone extensive testing and have been in operation at customer sites guarantee the level of quality already achieved in their functioning results, and any changes to them carry a high risk of introducing additional errors and degrading that quality, which limits the scope for radical modifications;
the work performed requires special, coordinated precision in making corrections and clearly regulated interaction among a number of specialists differing in qualification and level of responsibility;
the processes and results of maintenance are not marked by visibility or outward effect, or by any obvious display of their scale and complexity, and as a result they are not prestigious among rank-and-file programmers and are undervalued by project managers.
As the use of complex software products became more widespread, it became clear that the aggregate cost of their maintenance and of creating new versions can significantly exceed the cost of developing their first version. Experience in recent years has shown that in many cases the maintenance and monitoring of versions requires practically the same number of specialists as developed the first version of the software system, or even more. In creating complex software systems, the movement of specialists from developing new software components and systems to the development and maintenance of versions is systematic in nature. As a result, as the stock of operational software systems and their components grows, an ever-greater number of specialists move from directly programming new programs into the field of system design and the creation of new versions of software systems based on reusable components.
Only after the creation of several versions of the software system has been completed can the transfer of additional personnel into the sphere of maintenance and configuration management cease, and a stable ratio become established between the number of specialists engaged in the initial development of new projects and
software system maintenance. Developers of a new software system very often fail to anticipate this process and the resources it will require, which significantly reduces the efficiency of the subsequent use of the software product created. According to some estimates, direct programming of new components occupies about 15—20% of the specialists worldwide who are involved in creating software products.
The purpose of maintenance is to identify and eliminate detected defects and errors in programs and data, introduce new functions and components into the software system, analyze the state of and correct the documentation, replicate and control the distribution of versions of the software system, and keep the documentation and physical media up to date and secure — Fig. 15.1. The main task is to change and improve the existing software product while preserving its integrity and functional suitability. To preserve and improve the quality of complex software suites, it is necessary to regulate the processes of modification and enhancement of software systems, as well as support them with appropriate testing and quality control.
The widespread use of prototyping and the reuse of ready-made, proven software components has contributed to turning maintenance into a distinct branch of the methods and tools for ensuring the software system life cycle. Maintenance technology must ensure the coordinated development of multiple versions of the software system and its components, each of which has a sufficiently high level of quality and specific functions, and possibly also different users. As a result, over time software systems should improve and become more sophisticated both in their functional capabilities and in the quality with which each task is solved.
Maintainability — the capacity for regulated modification — is an important characteristic of a software system for customers, suppliers and users, reflecting the feasibility and ease of making changes to the software product after it has been put into operation. Requirements for maintainability must be included in the preparation during the ordering process, and their fulfillment should be assessed during the development of modifications to the software system. Various indicators may be used to determine and assess the quality of the modified software system,
qualitative and quantitative standardized metrics in accordance with ISO 9126.
Fig. 15.1
Maintainability must be defined before the initial development of the software system project begins, by way of a corresponding agreement between the customer and the developer-supplier. The developer must prepare a maintenance support plan reflecting the specific methods, the corresponding resources and the sequence of work. The efforts required to monitor and assess aspects of maintainability during development should be defined. Requirements for maintenance processes are determined by a group of key factors affecting the implementation of software system modification, which form a conceptual chain: change requirements — the functions to be changed — the size (scale) of the changes — the modification strategy — the resources needed to implement them. This logical scheme is usually used in the sequential analysis of the maintenance processes of complex software systems. Here, the main criterion for assessing maintenance is the improvement of functional suitability and the enhancement of the quality characteristics of the software product.
The main operational process in the life cycle can initiate the maintenance process of the software system by submitting proposals for modification (changes) or defect reports. The process of maintaining the software system, in accordance with standard ISO 12207 (clause 5.5), and its elaboration in standard ISO 14764, makes use of the main standardized process for developing software suites and the supporting processes of documentation, configuration management, quality assurance, verification, validation, joint review, audit, and defect elimination. The organizational processes of management, infrastructure creation, and training must be defined by the maintainer at the beginning of each maintenance project.
The cost of the maintenance process may account for a significant (even the largest) share of the cost of the software product's life cycle. The period of significant change in the size, functions and quality characteristics of large software-suite projects is usually 1—2 years. Research has produced the concept of the «critical complexity and growth in size» of the modified part of a software system version during maintenance. If, when a new version is upgraded and released, the size of the revisions noticeably exceeds the «critical» level, there is a high probability of a partial degradation of the system's characteristics, or of the need to release several intermediate versions to eliminate errors in the changes and achieve high quality in the modernization carried out.
The characteristics describing the qualitative and quantitative requirements for the maintainability of a software system are established by the customer. When carrying out the development, operation and maintenance processes, any defects detected must be described and monitored through the processes recommended in standard ISO 14476. In doing so, appropriate proposals for modifications or reports on the defects identified should be prepared. This process also determines whether the defects reported affect the need to modernize 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 baseline version of the software system for the organization of maintenance or may choose a third party (other than the developer) as the maintainer (see Fig. 15.1). Maintenance may also be carried out under an agreement between two parties within a single enterprise. These provisions must be applied regardless of whether the customer and the supplier belong to the same enterprise or to different ones.
The transfer of the software system for maintenance is a controlled and coordinated sequence of actions, in the course of which the product developed passes from the enterprise that carried out its initial development to the specialists or enterprise carrying out its maintenance. The transfer process must reflect:
requirements for the transfer of technical and software tools, data and knowledge (experience) from the developer to the maintainer;
the tasks of the maintainer needed to implement the maintenance strategy for the software product: staffing, training personnel, putting versions of the software product into operation, and disseminating maintenance experience.
Maintainers sometimes face the need to maintain a software product with a minimal set of documents or even with no documents at all. If the necessary documents are missing, the maintainer must create them, which is a mandatory part of complete, correct maintenance. In such a situation, when preparing for maintenance the maintainer must:
identify the problem area (the type of software product);
study any available documents, if possible discuss the software product with the developers, and work with the product itself;
study the structure and organization of the software product;
carry out an inventory of it, place the product under configuration management, build the product in accordance with the configuration management libraries, create scripts and call trees, and analyze the structure of the product;
determine the functions implemented by the software product; if possible, review the technical requirements (specifications) for the product and its general structure, analyze the call trees, read the program code, make the product available to other maintainers, and comment the program code;
establish priorities for modification proposals.
Maintainers must document the software product in accordance with the recommendations given above. The following documents must be updated or developed (as needed): technical requirements (specifications), maintenance specialist guides, user guides, and commissioning and installation guides.
The maintainer and the customer must conclude a maintenance agreement and specify in it the possible procedures for making changes to the software products under maintenance (see Fig. 15.1). The procedures may be used both by the developer of the original, baseline version of the software system and by an independent maintainer, and cover'.
the basic requirements and rules used to determine when a software system may be corrected locally, and when a new baseline version of the software product is required, using the development process for its preparation and installation;
descriptions of the types of version releases, depending on how often they occur or their impact on the operation of the software product (for example, emergency releases, periodic releases);
ways of informing the customer about the status of current or planned changes;
methods confirming that no additional problems or defects can arise as a result of introducing specific changes into the given software system;
classification of the type of change, its order (priority), and its relationship to other proposed changes.
To implement changes, the main process for developing the software system and its components must be planned and used, the requirements for which are supplemented by:established and documented criteria for testing modifications and assessing their results, as well as for assessing changed and unchanged objects (program modules, components and configuration items); and by the completeness and correctness of the implementation of new and changed requirements, so that the original, unchanged requirements for the software product are not distorted.
Maintenance personnel must verify the change introduced together with the customer who approved the modification, in order to confirm the functional suitability and operability of the corrected software product, and must obtain confirmation that the change introduced satisfies the requirements established in the agreement.
The specification of requirements for changes to the software system must describe exhaustively and unambiguously the mandatory requirements for the software system and its modifications, and must reflect the quality characteristics required by the standards. In doing so, the following factors affecting maintainability must be taken into account:
definition and description of new functions;
accuracy and logical organization of data;
interfaces (system, component and user interfaces), especially new and prospective interfaces;
requirements for functions and performance characteristics, including the effects of corrections and additions;
requirements imposed by the planned external environment;
the quality assurance plan for the modified software product, in which particular attention must be paid to the documents on changes and their consistency.
It is advisable to begin developing the maintenance concept with the formalization and justification of a set of source data reflecting the general features of the class, purpose and functions of the software system, its consumers, and the stages of the project life cycle, each of which affects the choice of specific characteristics for changing the software suite (see Fig. 15.1). For this purpose it is initially advisable to use the classification of software systems given in standard ISO 12182 and the entire basic set of
functional and quality characteristics standardized in ISO 9126. It is desirable to arrange their descriptions in advance by priority, taking into account the particular purpose, scope of modifications, and application of the specific software system.
At the stage of concept development and systems analysis, the goals of maintenance should be formed, the methods and algorithms for modifying the main functional tasks should be chosen, and preliminary quality criteria for the new program components and data being created should be formulated. Here, naturally, the question arises of the resources that will be required to achieve these goals and of the feasibility of their implementation. A purposeful and methodical expert assessment of the possible scale and resources needed for the changes reduces the magnitude of errors, although it usually still remains fairly large. To ensure reasonable reliability, initial forecasting should be carried out by extrapolation on the basis of specific accumulated data on individual, similar modifications of the software system.
Before the development of a new baseline version of the software product is complete, only approximate initial requirements can be formulated, reflecting the objects of modification and the conditions of their creation. Nevertheless, an expert survey of leading specialists makes it possible to draw up an initial scenario for the scale and conditions of the next modification of the software system. Even a qualitative classification and description of the characteristics of change scenarios significantly increases the accuracy of the forecasts made in the requirement specifications.
In the maintenance concept, the customer and the developer specialists must present the requirements, and document the plans and procedures for carrying out the work and implementing the tasks of this process. They must define procedures for receiving, documenting and monitoring defect reports and change requests from users, and for providing feedback to users. Whenever problems (defects) arise, they must be documented and entered into the resolution process. To analyze and eliminate them, the change and configuration management process for the existing software system should be implemented, and organizational procedures for interacting with this process should be defined. Defect reports and change requests must be analyzed for their impact on
organizational processes, the existing system, and the interface links with other systems, and the following must be established:
— whether it is a correction, an upgrade, preventive maintenance, or adaptation to new conditions;
the size of the change, its cost, and the time needed to implement it;
its criticality, and its impact on the main functions, performance, safety, or security.
On the basis of the analysis carried out, maintenance personnel must develop options for implementing the change processes and document: the defect report or modification request; the results of their analysis; and the requirements for implementing the changes. The options for change chosen must be agreed with the customer in accordance with the agreement. The maintainer must carry out an analysis and determine which documents, program modules, components or their versions require changes. The results obtained must be documented.
The description of the maintenance concept must be the first step in developing the maintenance policy for the software system. It must be developed at the time of the first release of the original software product, and must reflect:
the scope of maintenance and changes to the software product;
the practical application (adaptation) of this process;
the identification of the enterprise and persons responsible for maintenance;
an estimate of the cost and duration of maintenance.
The scope of maintenance must define the maintainer's responsibilities and the support that it is obliged to provide for the software product. It is often determined by the availability of the relevant resource and budgetary constraints, and must cover:
the types of permissible changes and maintenance procedures;
the quality level of the documents under maintenance;
the reaction (sensitivity) of users to maintenance;
the level of training provided to maintenance personnel;
the provision for delivering modified versions of the software product;
— the possibility of organizing a help desk — a «hotline». The concept must take into account the tasks of maintaining the software
product after its delivery. An important part of the maintenance concept is the identification of the resources and specialists (individuals or legal enti
ties), responsible for the maintenance of the product. This applies equally to the case of internal maintenance within the organization itself. If maintenance is carried out under an agreement with a third party, this must be noted in the maintenance concept. The choice of maintainer must be based on a number of factors:
the service life of the software system;
the amount of initial and long-term maintenance costs;
the qualifications of the maintenance personnel;
the functional suitability and operability of the original, baseline version of the software product;
the schedule for modifications and maintenance;
the maintainer's knowledge of the application domain of the software product.
An assessment of the financing terms and the cost of maintenance must be carried out. The cost depends on the size of the maintenance scope. Additional factors to be taken into account are the cost of: training both maintainers and users; and the software tool environment, testing, and their annual maintenance. When developing the maintenance concept, the cost is estimated on the basis of limited initial data. These estimates must subsequently be refined.
The development and approval within the concept of specifications of the requirements for the functional characteristics and quality of the software product taking into account the changes made should be carried out iteratively. A complete and one-time formalization of the requirements for the characteristics of each major modification at the beginning of the software system life cycle is usually impossible, primarily because of differing views held by the customer and the developers regarding the details of its purpose, functions and implementation possibilities within the available resources. The larger and more complex the software system project, and accordingly the higher its cost, the more carefully the requirements for its maintenance characteristics must be developed and resources allocated for their implementation.
When initially defining the requirements for functional suitability and for design characteristics, the resource constraints set by the customer may not always take into account a number of features of project maintenance, which will lead to an unacceptable reduction (or overstate
ment) of the requirements for certain characteristics of the modified software system. In addition, it is possible that some characteristics or their changes are contradictory or fundamentally unrealizable in the given project. As a result, unbalanced requirements and the available resources will manifest themselves as losses in quality or as a need to allocate additional resources.
Depending on the complexity of the project, the final result of the work in forecasting changes to the software suite should be detailed and approved requirements for the range, properties and quality values of the software product, sufficient for its full maintenance and subsequent effective operation. These requirements are fixed in the concept, the contract and the technical specification, against which the maintainer must subsequently report to the customer on completion of the modifications. However, at later stages of the life cycle and under configuration management, the requirements may be changed by agreement between the customer and the developer, most often timed to coincide with the preparation of a new baseline version of the software system. This requires monitoring of functional suitability, project scale, requirements, and the implementation of characteristics throughout the entire life cycle of the software system.
The fundamental and technical possibilities, the accuracy of implementing the properties and measuring the characteristic values of the software system, as well as the overall resources of a specific project, are always limited in accordance with their content and the capabilities of the customer and the developers. This determines the rational ranges of values for each change, which may be chosen in the maintenance concept of the software system on the basis of the customer's requirements, common sense, and analysis of pilot projects and precedents in the requirement specifications of implemented modifications. When the resources of a large software system project are limited, the distribution of priorities must become stricter, and the priority of characteristic changes for which resources are insufficient may be reduced. As a result, a complete set of the required functional and design quality characteristics is formed during the maintenance of the software system.
The requirements for functional characteristics and quality, approved after the concept has been designed, may be fixed in the technical specification as mandatory for detailed and working de
sign of the modifications (see Fig. 15.1). This data may be used in subsequent quality evaluation and when comparing it with the requirements during qualification testing and certification of the modifications or of the new baseline version of the software product.
For the customer and users, what may matter during maintenance is not only the determination of functional suitability, but also an assessment of the potential market demand for the specific software product, as well as its competitiveness compared with other software systems with similar functions, taking into account its quality and cost. This circumstance may determine the need to monitor implementation and refine the requirements for individual characteristics, not only during maintenance within the software system life cycle, but also for evaluating the integral quality of a new software product being brought to market.
In accordance with the requirements of standard ISO 12207 for the development and modification of a software product over its life cycle, a process for its maintenance must be organized (see clause 5.5). The work involved in providing maintenance for the software system includes:
process preparation;
problem and modification analysis;
modification implementation;
maintenance review and acceptance;
migration;
retirement.
These sections and the corresponding processes are detailed in standard ISO 14764 and are set out below with a number of comments. After the process is activated, a maintenance plan and the corresponding procedures should be developed, and specific resources allocated for maintenance. After the software product has been delivered to the customer, the maintainer, in accordance with the agreement and the modification proposal or defect report, must change the corresponding programs and documents. The source data is transformed or used in maintenance work to obtain output results — modified versions of the software product. It is recommended that regular monitoring be carried out to verify the correctness of the output results of specific maintenance work.
Fig. 15.2
During process preparation, the maintainer must create plans and define the procedures carried out in implementing maintenance (Fig. 15.2). It is advisable to create the maintenance plan in parallel with the plan for developing the first, baseline version of the software system. In carrying out this work the maintainer must also define the necessary organizational interfaces and relationships between specialists and with other enterprises. The source data for the process-preparation work are: the old (original) baseline version of the software product; the system documents; and the modification proposals and defect reports. To ensure effective implementation of the maintenance process, the maintainer should develop and document a maintenance strategy, which is one of the key factors in the use and development of the software system. In carrying out this activity, the maintainer must: develop maintenance plans and procedures; establish procedures for reviewing modification proposals and defect reports; and apply configuration management.
The maintainer must develop, document and carry out plans and procedures for performing the work and accomplishing the tasks of the maintenance process. The maintenance plan should describe the system's maintenance strategy, while the maintenance procedures must define the details for carrying out the stages and processes of maintenance. To ensure the creation of effective maintenance plans and procedures, the maintainer must:
carry out an assessment of the system under maintenance;
guarantee formal confirmation of accepting the duties of maintainer of the software product;
carry out an analysis of the resources available for maintenance;
assess and agree with the customer the financing and cost of maintenance;
establish requirements for the process of transferring the software product to the maintainer;
define the maintenance processes to be implemented;
document the maintenance process in the form of plans and procedures agreed with the customer.
The maintenance strategy must be oriented toward the human and material resources needed and available to support the development and modification of the software product. The maintenance policy for the software system must cover the following main components: the maintenance concept; the maintenance plan; and the resource analysis. The process of developing changes includes a number of activities related to planning the maintenance of the software system. These activities must be defined in the maintenance strategy of the software product: a threshold value of change, expressed in cost terms, must be defined that allows a corresponding change to be introduced into the software system without revising the specific agreement with the customer; and interface agreements for the whole project must be defined with regard to persistent problems associated with the vagueness, imprecision, variability, or unverifiability of the customer's requirements and specifications.
The purpose of maintenance planning is to prepare the plan for maintenance work and to secure the resources needed to carry out this work after the software product has been handed over for maintenance. Planning begins after the maintenance concept of the software system has been defined, and ends with the development of the maintenance plan, which is used as the basis for maintenance. The overall maintenance plan must define:
the reasons why maintenance is needed;
the composition of the personnel performing the maintenance work;
the roles and responsibilities of each party involved in maintenance;
how the main processes and work are to be carried out;
what resources are available and needed for maintenance;
the methods and tools for organizing management work, product release, and the synchronization of work;
a list of all project results and products to be delivered to the customer;
the criteria for completing the relevant activities, work, and tasks;
the composition of the reporting materials on the stages, costs, and schedules of the work;
the frequency and methods of issuing reporting materials;
the composition of the reporting materials on problems and defects eliminated;
— the start time and duration of maintenance. Maintainers are advised to formalize a specific plan
for the maintenance of the software system, drawn from the overall set of life-cycle processes presented above, refined and adapted to take into account the scope and features of the project, containing the following sections:
a description of the system under maintenance that includes the software system;
the maintenance concept for the software suite; a description of the level of maintenance of the system and the software system; the determination of the duration of the maintenance processes; the adaptation of standardized maintenance processes;
organizational maintenance work, and the roles and responsibilities of the specialists;
resources: the composition of specialists; tools; technical facilities; documents and plans;
processes — how specific activities are to be carried out;
determination of the level of training required for maintainers and for users;
— maintenance logs and reports; and control data collected during maintenance work.
The design of the architecture of the modifications determines the functions and components of the modified software system. The main features of this work among the processes of the software system life cycle that affect maintainability are the choice of program structure, its division into components (modules), and the flow of data circulating between them. In making modifications it is important to use the knowledge of the data-processing specialist team concerning the possibility of using parts of existing programs or libraries that have demonstrated high functional quality. The main means of ensuring maintainability requirements are a modular architecture combined with top-down analysis, and the corresponding documents, to which additions may be made as needed.
During the design of the software system, versions of each component of the software system, of the interfaces, and of the databases are created. Precise, detailed descriptions of each function are drawn up for implementing the proposed changes. The maintainability of the software system can be improved by taking into account the quality characteristics regulated in standard ISO 9126. The maintainer should define procedures for: receiving, documenting and monitoring defect reports and modification proposals from users; and providing feedback to users. Every problem and defect that arises must be documented and entered into the change-analysis process, for which purpose it is necessary to:
develop a scheme for classifying and assigning priorities to proposed modifications and defect descriptions;
develop procedures for conducting targeted change analyses;
define procedures for the operator to submit proposed modifications and defect descriptions;
define the organization of feedback to users during change analysis;
determine how users will be served during the implementation of maintenance;
determine how the proposed modifications will be entered into the database for tracking the status of changes and the resources used.
The analysis of defects and modifications in standard ISO 14764 is recommended to be carried out in the following order:
the modification proposals and defect reports are analyzed;
each defect is duplicated or its reality is verified;
options for implementing the change are developed;
the following are documented: the modification proposals and defect reports, the results of their review, and the options for implementing the changes;
the chosen option for implementing the change is agreed with the customer.
Before making changes to the system and the software system, the maintainer must: analyze the possible changes from the point of view of their impact on the enterprise's activities, the existing system, and systems interconnected with it; develop and document recommended alternative solutions for introducing the corrections, and agree the decision made on introducing the changes with the customer. The maintainer needs to analyze the problem report — the defect or modification proposal — in terms of its impact on organizational matters, the existing system, and the interface links with other systems, by type: correction, upgrade, preventive maintenance, or adaptation to new conditions or environment; by scale: the size of the change, its cost, and the time needed to implement it; and by criticality: its impact on the operating characteristics and performance, safety, or security of the product.
To ensure the implementation of a submitted change proposal, the maintainer must determine:
the availability of appropriate personnel capable of implementing the proposed change;
availability of sufficient funding to implement the proposed change to the program;
availability of the appropriate computer resources and the degree to which the modification affects the version of the software product being implemented or already implemented versions;
whether the absence of the proposed changes affects the requirements for system interfaces, the expected service life of the system, and priorities;
the effect of the changes on the safety and security of the system during operation;
one-time and long-term costs of the correction;
the benefits obtained after the modification is carried out;
the effect of implementing the changes on the schedules of work on the version of the software product;
the necessary processes of verification, testing and evaluation of the characteristics of the system and software product after the correction has been made.
In order to confirm the relevance of the submitted defect reports, the maintainer must reproduce and verify the problems — defects that have arisen, by performing the following steps to solve this task: develop a verification and qualification testing strategy to check that a specific problem — defect has been eliminated; carry out testing to check for the presence of the problem — defect; document the results of the qualification testing. If a specific problem cannot be reproduced by the maintainer, he must check the enterprise's rules, policies and software life cycle support documents. Based on the analysis performed, the maintainer must develop options for implementing the change:
assign the appropriate priority to the problem (defect) or to the modification proposal;
determine whether the capabilities and means for solving the problem are available;
assess the scope and labor intensity of this modification;
develop options for implementing the specific change;
determine the effect of these options on the functional suitability and technical means of the system;
perform risk analyses for each modification option.
The maintainer must implement a configuration management process for managing changes to the existing system, or define an organizational interface with this process (see Lecture 16). The results of this work are: a maintenance plan and procedures; procedures for problem resolution and defect elimination; plans for organizing feedback with users; a plan for delivering the modifications to the customer and users. Before making changes to the system and the software product, in accordance with the contract with the customer, the maintainer must agree on the chosen correction option.
Control over the work under consideration should be carried out through the joint review process. At the end of the work, a risk analysis must be performed. Based on the output results of the analysis, the preliminary estimate of the required resources may be revised, and, with the involvement of the users or the customer, a decision is made on the feasibility of proceeding with the work of introducing changes into the baseline version of the software product. The results of this work are: an analysis of the effect of the changes; the recommended option and the agreed changes; updated and corrected documents.
When changes are made to the software the maintainer develops and tests the specific changes to the software product. The input data for carrying out the work of making changes must be: the baseline version of the software product; modification proposals agreed with the customer; agreed documents for implementing the correction; a report on the effect of the correction and the output results of the change analysis work. The maintainer must perform an analysis of the use of the program suite development processes when making changes. After the correction has been agreed, the maintainer should carry out an analysis and determine which documents, program modules and their versions require changes. The results of this additional analysis must be recorded in the set of documents of the development process for the baseline version of the software product:
— the components in the existing system subject to change have been identified;
the components of the specific interface affected by this change have been identified;
the documents subject to update have been identified;
the set of documents for the baseline version of the software product has been updated;
the criteria for conducting qualification testing and trials, and for evaluating their results in the changed and unchanged objects (program modules, components and configuration items) of the system, have been established and documented;
the completeness and correctness of the implementation of the new and changed requirements have been ensured, and it has been ensured that the original, unchanged requirements and the integrity of the system have been preserved.
The results of the correction trials must be documented. Control over the work under consideration must be carried out through the joint review process. The results of this work are: updated test plans, documents and procedures; changed source programs; qualification testing reports; indicators characterizing the quality of the changes made. The updated documents must include: a detailed report on the analysis performed; updated requirements; updated test plans, procedures and reports; updated training materials.
Verification and acceptance of modifications during operation ensures confirmation of the correctness of the changes made to the system, in accordance with the accepted standards and the established methodology. The input data for carrying out the verification and acceptance work during maintenance are: the changed software product; the results of the qualification testing of the changes made. Verifications are carried out to guarantee the correctness of the changes and their consistency from the standpoint of meeting the customer's established requirements for the software product. The maintainer must carry out verifications of each change made together with the customer who approved the change, in order to confirm the integrity and operability of the changed system:
— tracing implemented modification proposals and defect reports against the requirements of the previous baseline version of the project and the program code;
verification of the testability of the program text (code);
verification of compliance with the standards for the software and system life cycle;
verification that only the necessary components of the software have been changed;
verification of the correctness of the assembly of the new components of the software product;
monitoring of the update of the documents for the version of the software product;
verification of the completeness of the testing performed and of the test reports.
The maintainer must obtain agreement and confirmation that the change made satisfies the customer's requirements established in the contract, through the supporting quality assurance process; verification that this process has been carried out; and the conduct of a functional and physical configuration audit. The results of this work are: a new baseline version of the software product incorporating the accepted changes; rejected changes; a version acceptance report; audit and review reports; a report on the qualification testing of the software product.
An important role in the successful introduction of new versions is played by the psychological aspect. Favorable conditions for introduction are ensured where there is normal interaction between the customer, users and developers during the creation and modification of versions of the software product. This contributes to a fairly high degree of refinement of the documentation and tools by the developers, and to the timely understanding by users of the functional purpose of the software components, their features and new capabilities. The main psychological difficulty lies in the fact that large teams of specialists have to be moved over to new methods of work. Particularly great difficulties arise when a version of the software product is introduced at the pilot operation stage, when the flow of errors is significant for various reasons (inexperience of the user, poor-quality documentation, an unrefined system). An additional difficulty may be associated with certain limitations inherent in applying, for maintenance and the implementation of changes, a new technology and tools that often differ from the customary ones.
The maintainer must document and submit to the customer:
reports on problems (defects) and modification proposals; the results of their analysis and options for implementing the changes;
the results of the acceptance trials, verification, certification and measurements of the quality characteristics of the new version of the software product;
reports on ensuring the quality characteristics of the software product and the results of their testing;
the results of the audits of the version of the software product;
the customer's comments and the results of interaction with the customer on eliminating defects in the version of the software product;
a set of up-to-date project documents and maintenance results documents;
assessments of the correctness of the implemented policy, schedule and qualification testing Program for the version of the software product;
the ratio of estimated to actually used resources;
official recommendations indicating expedient subsequent modifications and the creation of new versions of the software.
Introduction of a new version of the software product for widespread use (see Fig. 15.2) is carried out, as a rule, in two stages: by the modification developers themselves, for the purpose of running-in, checking and identifying errors in the changes at the pilot operation stage; and through the use of specialized maintenance teams for replication and distribution. The main duties of the maintainers amount to delivering the physical media containing the software codes and the set of operational documentation, as well as conducting consultations for the designated group of user specialists. In this case the maintainers get the opportunity to directly monitor the work of the users with the system and the documentation, which ensures a high degree of responsiveness in handling comments and claims, the formulation of qualified change proposals, and the assessment of the effectiveness of using the version of the software product. In addition, a training and methodological plan is developed, training aids needed for training users on courses are prepared, and training is conducted for the designated group of specialists responsible for the subsequent training of user teams and for maintaining the software.
The use of versions of the software product by users is regulated by established rules and is fixed by the relevant contracts. These contracts determine the procedure for delivery, installation, commissioning and maintenance of software versions, as well as the procedure for training users. The most favorable conditions for successful introduction are created when the development of software modifications proceeds according to the new technology from the very start of the project. Nevertheless, there are known examples of connecting a new maintenance technology to software with a certain inherited legacy. Such a situation is usually typical of complex, operational software undergoing significant modernization or development, or when the project development deadlines are running out and attempts are made to increase development efficiency by applying a new, advanced maintenance technology.
When training maintainers, the main attention should be devoted to presenting the methodological foundations and the standardized, technological operations for developing program modifications. Thus, it is advisable to train specialists starting from technology and standards and moving toward tools. This approach makes it possible to make the most rational use of automation tools in the process of developing changes to software of various types and purposes. The introduction of methodological principles for developing program modifications and maintenance technology ensures their unified and effective use by different specialists working both within a single program suite and on different, independent projects.
Withdrawal of a software product from operation and maintenance must be prepared by an analysis substantiating this decision. The analysis should determine and economically justify: the possibility of retaining the outdated version of the program suite, as well as the need to create and apply a new version of the software product. When withdrawing the software product from maintenance, the actions necessary for this should be determined, and the stages of work ensuring their effective performance should then be developed and documented. Provision must be made for access to the archived data of the base software product withdrawn from maintenance.
The specialists carrying out the withdrawal of the software product from maintenance and operation must draw up a plan, notify the
users of this, conduct appropriate personnel training, notify all interested parties of the completion of maintenance, and archive the relevant data. The content of the plan should include:
an analysis of the requirements for withdrawal from maintenance and operation;
an assessment of the effect of withdrawing the software product from maintenance on the system;
identification of the software product replacing the one being withdrawn (if one exists);
a schedule and a Program for withdrawing the software product from maintenance and operation;
determination and documentation of all procedures for withdrawal from maintenance and operation;
the timeframes for terminating full or partial maintenance support;
requirements for archiving the version and modifications of the software product and the corresponding documents;
the timeframes for transitioning, if necessary, to a new version of the software product;
requirements for access to the archived copies of the software product project data.
For a smooth transition to the new baseline version of the software product, parallel operation of the previous and new software products must be ensured. Over a certain period of time, the necessary training of users in the new version should be carried out in accordance with the terms of the contract. After the planned withdrawal from operation has been completed, a corresponding notification must be sent to all interested parties. Everything related to the previous version of the software — development documents, registration logs and programs — must be placed in the archives. Data used in, or related to, the software product withdrawn from operation should be kept available for audit. It is also advisable to retain old versions of the software and certain data obtained when solving previous tasks, for use as tests; to make copies of the old software and the data obtained when solving previous tasks; and to store the relevant media in a secure location.
Extensive duplication of what are essentially the same software tools and database information on similar or different platforms entails significant irrational costs for their development and an increase in the time needed to create information systems. Reducing these requires organization, technology and tooling that ensure the efficient porting of ready-made programs and data within a single operating and hardware environment or from other platforms. For this purpose, porting methodologies and technologies are created, as well as standards supporting the processes and development of portable programs and data. In each specific case, an assessment of the cost-effectiveness of the porting is needed, taking into account a number of factors characterizing the mobility of the programs and data and their environment, compared with the full development of a similar software product on the new platform. The use of methodological, technological, algorithmic and program groundwork from previous
продолжение следует...
Часть 1 15. Maintenance and monitoring of software systems
Часть 2 15.4. Resources for Providing Maintenance and Monitoring of Software Systems
Comments