Lecture
Это окончание невероятной информации про сопровождение программных средств.
...
projects provides a multiple increase in the productivity of system developers, a reduction in the time needed to create them, and high project quality. By mobility — portability are meant:
the processes of porting programs and data from one hardware, operating and user environment to another environment differing in architecture and characteristics, with their integrity preserved or with only minor changes to the functions of the system;
the processes of reusing ready-made software components and tools, as well as database information, possibly within a single hardware and operating environment architecture, for extending and changing the functions of the system and the software product.
The main incentive for developing and applying mobile programs and data was the need to improve the economic indicators in creating and operating complex systems, as well as to raise their quality. The objective requirements of customers and users for improving and reducing the costs of informatization of objects and processes were reflected in the formation of the principal goals of creating and applying mobile programs and data, which consist of the following:
ensuring the preservation of the investments made in implemented and proven software products and databases during their development, modification and the emergence of new requirements for them, as well as during the improvement of architectures and the growth of resources and functions of hardware and operating platforms;
reducing the labor intensity, cost and duration of the direct development of complex distributed software and databases;
ensuring high quality, reliability and safety in the functioning of software and databases within systems;
ensuring the possibility of porting, with minimal changes, proven and properly developed software products to various operating systems and hardware platforms in a way that is effective in terms of economic indicators and quality;
cost-effective implementation of joint operation and the extension of the software's functions (interoperability) in interaction with other programs and data when solving a single target task on various local and distributed platforms;
ensuring interaction with users in a unified style that makes it easier for them to move to using new systems and software products, or ones with extended functions (user mobility);
reducing the dependence of the customers of specific systems on particular suppliers of hardware and operating platforms, as well as on the developers of certain software products.
Achieving the listed goals in ensuring the mobility of software requires various resources for their implementation. The need for specific resources and the cost-effectiveness of their use depend on a number of parameters that form a wide range of situations for analyzing and applying the mobility property of programs and data. Such resources are:
the labor costs of specialists and the time spent on creating, acquiring and operating tools that automate the development and maintenance of mobile software and databases;
the labor costs of specialists and the time spent on creating additional interface components in programs and data that ensure their effective mobility to specific types of platforms, for example, in accordance with the concept and standards of open systems;
— additional memory and computing performance resources needed for implementing and operating the components in programs and data that ensure their high mobility, for example, for implementing standardized interfaces with the external and internal environment.
The tasks of reusing and porting programs and data cover:
embedding a ready-made software tool and database information into the new system being created, provided that their suppliers guarantee operation on the chosen platform;
porting programs and data from the platforms in whose environment they were previously implemented, to the new platform chosen for the system;
ensuring access to the information resources of other distributed systems and networks.
When porting, the properties of software products practically always change, which should be taken into account when analyzing the feasibility of the porting, and their debugging, testing and certification in the new environment may also be necessary. It should also be borne in mind that any porting is associated with costs, which are most often required for:
systems analysis of the cost-effectiveness of porting to a different or the same platform, and evaluation of the technical and economic indicators of this process;
carrying out the actual porting process and integration with the operating and external environment on the new hardware platform or in the existing environment;
qualification testing, trials and comprehensive verification of the functioning of the software product in the new environment or on the new platform;
certification of the product ported to the new platform and functioning in a different operating and external environment;
— the correction or supplementation of the operational and technological documentation.
The last two types of work may be carried out during the creation of mobile software and databases, and may be absent when the porting itself is carried out directly. However, even in this case, excessive optimism should be avoided
when estimating the costs of porting, since when creating mobile software it is difficult to foresee all the possible features of the various platforms and the external environment for which the mobility of specific tools is declared. These features and the possible expansion of the surrounding application programs and data can present unpleasant surprises of incompatibility, the elimination of which will require additional costs.
The integration trends in the development of modern software and databases are associated with the combination within them of tasks belonging to different classes. This determines the need to apply different tools for implementing programs belonging to different classes, as well as the need to ensure the functioning, within a single target system, of programs created by different methods. The analysis of the mobility of programs and data in systems concerns various classes of tasks; however, for the sake of definiteness, the specific methods and tools for ensuring mobility are considered below mainly in relation to data processing tasks in distributed systems. In this case, the objects of portability analysis are:
program modules and functional components of the software;
ready-made (off-the-shelf) software products and application program packages;
large program suites of a specific functional purpose;
database management systems;
files and information arrays of databases;
electronic documents for programs and data.
The main features of reusing programs and data in systems determine two groups of tasks: the structuring of programs and data at the analysis and design stages of systems, involving the sequential decomposition of the specified functions of the system, which makes it possible to identify components that can be reused as ready-made ones, and to describe their interaction with other components; and also the assembly or integration of components and comprehensive, qualification testing of the system as a whole. A significant part of the methods and tools of modern software engineering is directed at ensuring the mobility of programs and data. A clear separation of the results of the work,
performed at each stage of the software life cycle, and certain conditions for transitions between the life-cycle stages, make it possible to distinguish the following levels of porting and reuse of software:
domain models and requirements specifications, possibly implemented in different ways at the software design stage;
design specifications of requirements at the software development stage;
source code of programs in the programming languages used when developing the reusable program components;
object code of programs, when structural and hardware compatibility between the source and target (implementing) platforms is ensured;
file structures and database information;
tests for verifying the functioning of components, tests for verifying the compliance of reused programs with standardized interfaces, and comprehensive tests.
The processes of porting programs and data to other platforms, the choice of methods for ensuring the mobility of software, and the characteristics of the resources used for their implementation depend, above all, on the parameters of the components intended for porting. Resources are needed to one degree or another at two phases of the processes of porting programs and data:
during the creation of potentially portable software and databases, when the properties of effective mobility are envisaged and implemented during their development, and the possible platforms and areas of reuse of such programs and data are determined;
during the direct implementation, with the corresponding costs, of the processes of porting software and databases prepared, to varying degrees, for porting to other platforms or for reuse on the same platform.
When analyzing the first phase, it should be taken into account that a large volume of program suites and components and of database information has been accumulated to date, in the creation of which the possibility of their subsequent porting to other platforms was not taken into account — the so-called legacy systems. Moreover, because of the limited computing resources available when implementing large functional tasks
the programs and data in such systems were usually adapted, during development, to the maximum extent possible to the features and parameters of the computer in order to make effective use of its resources. An extreme case is provided by: onboard computers, with the corresponding software, for aviation, missile and space systems, in which the limitations on the weight and dimensions of the equipment give rise to increased requirements for the efficiency of using computing resources.
Depending on the degree of program compatibility between the source and the new, target platforms, the following options for applying mobility can be considered:
in the case of complete platform incompatibility, it may be necessary to develop the entire program suite anew (possibly using the available requirements specifications and reengineering methods);
in the case of incompatibility of the programming languages or of the dialects of a single language, the software programs must be rewritten in the language adopted for the new system's project (possibly using the available design specifications and embedded reusable components);
in the case of incompatibility of the hardware-software platforms supporting the same programming language, the software code must be recompiled on the new platform (possibly with automatic optimization provided by the programming system used);
when binary compatibility of the architecture of the source and new platforms is ensured, porting is achieved by directly executing the software on the new platform (possibly using tools that emulate certain components of the source platform's architecture).
The tasks and objects related to the mobility of software and databases in systems and subject to consideration when selecting methods and tools for ensuring portability, include:
— unified protocols and interfaces for the interaction of software components with one another, with users, and with the external environment, which include, above all, application programming interfaces determined by the chosen architecture of the system environment, including operating system interfaces, network protocols, and specifications of services for organizing processes running on top of operating systems;
programming languages and tools supporting the creation of portable software and database systems, and software engineering tools — CASE systems;
database languages and database management systems;
data formats, formats of external electronic messages;
— formats of portable electronic documents. The effectiveness of the selection and identification of components for reuse
and porting to other hardware and operating platforms depends, above all, on their size and on the multiplicity of possible application. When developing small-scale software (of the order of a thousand lines of source code), searching for and selecting ready-made components for use in the new software most often proves unprofitable. Thus, there is a certain range of small sizes of programs and database information for which it is inexpedient to apply previously created programs and data arrays. Based on this parameter, the following porting methodologies can be identified:
complexes of program and information components, as well as the operating environment as a whole, solving all the functional tasks of a particular complex system and fully preserving their structure on the new hardware platform;
sufficiently autonomous, large software and arrays of database information solving additional functional tasks in interaction with the operating tools available on the new hardware platform;
individual modules or small functional components of programs and information data arrays for extending and improving the functions of functional tasks previously implemented on the same hardware and operating platforms.
The design of systems using reusable components becomes especially cost-effective for large software, containing hundreds or thousands of modules, and with large volumes of processed information. The multiplicity of application of components also significantly affects the efficiency of their porting. It is particularly advisable to carry out thorough debugging, interface unification and documentation preparation for those components that will be used in future
repeatedly, by different specialists, in different versions of the software, and on the same or different platforms.
Porting of programs to computers with a different architecture and operating environment at the level of the source text of programs and data in high-level algorithmic programming languages is the most widely used. In practice, one has to deal with a multitude of situations of porting programs and data between non-matching hardware and operating platforms, as well as with differing degrees of mobility of the source software and databases subject to porting, and with the technologies used to create them. This variety of situations determines a wide range of values of porting efficiency in terms of the resources required to carry it out, and the choice of rational implementation methods. Therefore, in each specific case it is advisable to carry out a factor and technical-economic analysis of porting efficiency and to plan its implementation.
The processes of porting software and databases are regulated by a number of procedures and documents standardized in ISO 14764 (clause 8.5), which details the requirements for the porting processes defined in the base standard on the software life cycle (see ISO 12207, clause 5.5.5). Specialists who carry out porting according to the recommendations of these standards must develop a porting plan, notify users, train personnel, issue warnings about the completion of the porting, assess the effect of the new version and the external environment, and archive the relevant data. If a system or software product (including data) is transferred from the old to the new operational environment, it must be ensured that the software product and data are correctly changed during porting. For this, the following main tasks must be solved: identify all the program components, products or data being added or changed; verify the compliance of the implementation of specific tasks with the customer's requirements specifications for the ported version of the software and database.
To control the porting of the system, it is necessary to develop, document and carry out a software product porting plan. Users may be involved in the planned work. The content of the plan must include:
— analysis and formulation of requirements for the results of the porting;
development (or acquisition) of tools for carrying out the porting;
configuration of the software product and data for the new operating conditions and environment;
execution of the porting processes;
verification and testing of the porting results;
ensuring subsequent support for the previous environment and software product.
Development of the porting plan must be based on the initial data and the requirements of the customer or potential users. After the maintainer completes the porting planning, a notification must be sent to the customer and users about the plans and work for porting the software product and database. It is advisable to include in the content of the notification: an explanation of why the previous environment and software can no longer be maintained and supported; and a description of the new environment and software product, indicating the date from which they are available to the customer and users.
The maintainer must also present to the users the porting procedure plan and schedule (Program) and solve the following tasks:
identify all the components affected by the porting;
work through feedback and information with the customer and users;
determine the specifics of the users;
publish the porting schedule (Program).
For a smooth transition to the new environment, users may carry out work in parallel in the previous and new environments, with the corresponding versions of the software and database. The maintainer must carry out the following personnel training work:
determine the training requirements for implementing the porting;
plan the implementation of the porting training requirements;
verify the training results after the porting has been carried out;
update and correct the training plans.
After completion of the planned porting, the corresponding notifications must be sent to all interested parties. All documents, registration logs and pro-
grams related to the previous environment should be placed in the archives. After completion of the porting, it is advisable to conduct a final analysis to assess the impact of moving to a new hardware and operating environment on various aspects of the operation of the migrated software product. The results of the analysis must be sent to the relevant stakeholders for information, guidance, and use in their work.
The reporting results of the software and database migration work are:
the migrated software product on the new platform;
the migration implementation plan;
migration tools;
notices of intent to migrate;
notification of migration completion;
archival data on the migration processes and results. The most complex and labor-intensive case is the migration
of a legacy software suite and database information to an incompatible, entirely new hardware and operating platform. In this case, it may be necessary to preserve a large volume of accumulated database information and the user interface. In this case, the algorithms or specifications of the information processing tasks may be preserved and migrated, and the migration of the accumulated database information must also be specially organized. Changing the platform and expanding its parameters may make it advisable to modernize the algorithms. As a result, an essentially new system will be created using the overall system foundation and database information.
There are many portable application software packages created using modern tools. These software and database development automation tools have dramatically simplified the migration processes and, in a number of cases, reduced them to the automated translation and adaptation of the selected packages to platforms of certain types. At the same time, the technology of creating software and databases by migrating them to other hardware and operating platforms has undergone a qualitative change and is actively developing based on the concept and standards of open systems (see Lecture 3).
When analyzing databases as objects of migration, it is advisable to consider two components: the data management system (DBMS) and
a set of data organized according to certain rules. The simplest option for migrating database information to a different hardware platform is implemented when both platforms have proven DBMSs of the same type and version. In this case, it is assumed that there are no additional technical restrictions on placing all the database information and no need to change or adapt its structure on the new hardware platform. In this case, the main work comes down to migrating the entire volume of database information and, after that, testing the operation of the DBMS on the new platform for compliance with the documentation of the original DBMS version with the migrated information. In this case, the labor intensity and duration of creating the database on the new platform are determined mainly by the work on migrating the database information and testing the new system.
However, more often, subsequent migration of the database is not planned when it is first formed and populated, and arises after prolonged operation of thelegacy system. The reason is usually unsatisfactory database performance quality indicators, the need for additional memory resources and computer performance, and insufficient response time to data queries. In this case, an extreme situation is possible, when it is necessary to migrate database information with a not fully known structure and relationships under the control of a completely different type of DBMS on a different platform, with greater resources and capabilities. The complexity, labor intensity, and duration of the database migration in this case increase significantly and require careful planning and organization of the work, approaching the creation of an entirely new database.
The cost and complexity of migrating database information depend primarily on its characteristics, which reflect the format, linguistic, and physical compatibility of the content of the migrated database between the platforms under consideration:
format compatibility is characterized by the degree to which the data in the databases of the platforms being analyzed conforms to the requirements of the standards for data representation formats for documentary, factual, dictionary, or other databases;
linguistic compatibility is determined by the degree to which the databases under consideration use unified linguistic tools (classifiers, subject headings, dictionaries) formalized by the relevant standards;
— physical compatibility consists in the degree to which the encoding of the database information conforms to the same standards for machine-readable storage media.
If the DBMS software is migrated in full together with the database information, this ensures that the data management functions are preserved. However, it may be necessary to migrate the database information to a different hardware platform with a different type of DBMS. In that case, the migration task becomes more complicated.
For medium and large projects, it is advisable to conclude the systems analysis of the migration with an estimate of the total labor intensity and duration of the software product migration and their comparison with a complete development of the software and database using some of the algorithmic and system groundwork. In addition, the resulting software suite should be evaluated in terms of memory usage and the performance of the new computer. Such an assessment must be carried out taking into account the possible distribution volume of the software and the prospects for its long-term operation. A focus on reducing costs during program migration is often reflected in significant losses in system operating efficiency due to an increase in the volume of programs in object code and a decrease in their performance, especially when the software product is used for a long time on many computer instances in real time.
Forecasting the necessary basic resources — labor, time, and the number of specialists involved in the maintenance and monitoring of complex software suites is complicated by the fact that the costs of changes consist of two fundamentally different parts. The first, usually the smallest, part of the changes is characterized by the costs of detecting and eliminating defects and errors in the software, the occurrence of which is unpredictable and has large fluctuations depending on the characteristics of the project, the qualifications of the specialists, the tools used, and a number of other factors that are difficult to take into account. It is hardly possible to estimate and forecast such costs a priori when maintaining specific software products, and
they are not discussed below. The second part of the changes is governed by purposeful improvement and orderly modifications of software product versions, the scale of which can be forecast in advance with a certain degree of reliability. Such changes can serve as a basis for determining the possible costs of developing additional functions and significant modifications of software versions, which can be generalized over a certain maintenance time interval or for the project as a whole.
When analyzing the costs of software maintenance and monitoring, it is advisable to consider the following scenarios:
determining the size of individual local modifications of programs and data practically without regard to interactions with the rest of the software product version, owing to its clear structuring and the ability to isolate the size of the specific function being changed;
the aggregate resource costs of implementing each modification that has deep interconnections with many components of the entire large software product, in which it is necessary to take into account not only the size of the specific change but also the magnitude of its impact on the entire software suite;
evaluating the integral costs and aggregate size of changes during maintenance and configuration management of the software and database over a certain time interval (month, year), taking into account the entire set of changes.
The first stage of forecasting the necessary resources during maintenance is the creation of a set of requirements for the specific modification of the software product's functions, into which the actual components that determine the functional suitability of the software can be broken down. This breakdown can subsequently be further detailed, forming a simplified or more precise level of abstraction and interaction of the components being changed. It should be taken into account that a maximally detailed structure of the software can be useful at the stage of preliminary estimation of the size of the software modification. One way to estimate the size of changes to software that is at the project concept stage is to compare its functional tasks and properties with already existing versions. When justifying the resources needed for maintaining complex software, three key factors are of greatest importance:
size — the scale of the completely new or modified software components to be developed;
the size and relative share of ready-made software components that can be borrowed from previous projects and reused for modifications in the next version of the software product;
the relative resource costs of creating modifications and new software components with an estimated scale of changes: the labor of specialists, time, budget per unit of size (per line of program text), or the total cost of developing the entire new software version.
These factors can be assessed by qualified experts based on their experience of monitoring and implementing previous similar modifications. The reliability of the forecasts of the required resources depends, above all, on the accuracy of the assessment of the initial requirements for improving the software product. They make it possible to use the experience of past developments and their differences from the new methods and functions envisaged in specific projects, as well as the individual capabilities of the development team or other unique features of the specific project. If the listed initial data are available and there is a positive assessment of the advisability of expert analysis and forecasting of resources for software maintenance, they should be used for:
estimating the size — the scale (number of lines) of the intended change to the text of the new programs being developed, taking into account the size of the ready-made reusable components and the characteristics of the possible programming language;
calculating the possible total labor intensity and duration of developing corrections to software versions, as well as the average number of specialists needed to implement them;
generalizing the main technical and economic indicators and estimating the total cost of software maintenance, analyzing the results, and justifying the cost-effectiveness of continuing the monitoring, modification, and maintenance of the software suite.
In the technical and economic feasibility study (see Lecture 5) of a software project's maintenance, it is advisable to apply methods and techniques that are adequate to the goals and stages of its implementation. When beginning the development of modifications
to a software suite, as in any professional activity, it is first necessary to conduct a realistic assessment of the possible change in the project scope — the stated goals, project resources, and allotted time. The task of scope management is to define the baseline requirements, which include a limited set of additional functions and requirements, broken down into components, planned for implementation in a specific version of the project. The baseline level of changes to the scope of the software must ensure:
a minimum of additional functions and requirements for the software product version that is acceptable to the customer;
a reasonable probability of success in terms of the capabilities of the maintenance team and the modification developers within the required time.
The need for resources, the volume of functions to be implemented, and the specification requirements for modifications depend to the greatest extent on the permissible size —the scale and complexity of the modifications to the software being maintained. The main purpose of assessing changes to the scope of the software — is to prepare the ability to make an informed decision on the permissibility of further monitoring and maintenance of the project in the area of systems analysis, requirements development, and design of modifications and new versions of the software product. If it turns out that the initially calculated scope and required resources for changes to the software cannot be provided by the customer for continued maintenance, then radical decisions are possible: either changing some of the allocated resources or discontinuing the monitoring and modification of the given software product.
To reduce possible methodological errors in resource estimates for software maintenance and modification, one should begin by forecasting the size of the changes or the new version of the software product, the reliability and errors of which may be caused by the following factors:
the problem, purpose, and new additional functions of the software may not be sufficiently well understood by the modification developers and/or the customers because certain significant factors were overlooked or distorted due to a biased attitude toward them;
the specialists estimating the scale of the changes to the software version may make significant errors when trying to describe how large the changes to the system or software suite could be before the stage of developing the concept or the preliminary design of the modification;
the enterprise maintaining the software does not have standards and methods that can be used to carry out the initial process of assessing the scale of the software modification (or, if standards exist, no one adheres to them);
project managers and specialists believe that it would be worthwhile to record the possible changes in scope and requirement specifications at the beginning of maintenance, while customers often believe that it is not worth spending valuable time on estimating the size of upcoming modifications and on the detailed development of maintenance requirements.
The costs of software maintenance can be estimated by the need for labor and time resources for its provision and implementation. These costs consist of two related parts: the costs of implementing the corresponding quality characteristics that ensure effective maintenance of software products, and the costs incurred when using these characteristics during the operation of the software suite. Improving quality and increasing the costs of implementing the characteristics usually helps reduce the costs during their operation. The latter are difficult to estimate a priori, since they depend on the external environment and the intensity of use of the specific software, rather than on its properties and the required quality. (According to some estimates, the number of specialists involved in maintenance for expanding functionality and improving software quality (= 40%) and for eliminating defects (~15%) exceeds the number of specialists engaged in creating new programs (~ 45%)).
The cost and duration of maintaining components or a software suite can be determined by a contract between the customer and the supplier based on precedents from similar projects, taking into account the changing market conditions. The costs of providing and carrying out software maintenance are determined by the duration of the software suite's life cycle; its portability, the level of automation of the development technology, and the production run of the programs. To estimate them, it is first of all necessary to identify the main types of costs involved in maintaining a specific software suite and the most significant factors that affect them. Such an analysis can provide guidelines for forecasting the total maintenance costs and for estimating this characteristic for specific
software projects. In this case, it is important to take into account the ratio of development costs to maintenance costs over the life cycle of the entire production run of the software.
Unique, custom-built software, most of whose life cycle is spent on development, can be created with almost no regard for subsequent maintenance costs. However, software that is repeatedly upgraded and widely distributed requires significant maintenance costs. Due to the long period of maintenance and operation (in some cases more than 10 years), as well as the large number of versions containing the results of upgrades, the aggregate maintenance costs in some cases significantly exceed the costs of the initial program development. These costs are distributed over the entire maintenance time interval, as a result of which the costs of preparing each version are usually lower than those of the initial software development. Long-term maintenance sometimes causes repeated changes of the specialists carrying out the maintenance. Such replacements incur significant costs for training the new maintenance team, which causes an increase in the total costs. Maintenance costs can be reduced through some increase in the costs of software development, so that with rational design the total costs can sometimes be reduced quite noticeably.
In systems analysis, maintenance costs can be considered additive and include the following components'.
the costs of detecting and eliminating errors and defects in each software version;
the costs of refining and improving programs, and forming and testing new upgraded versions of the software;
the costs of replicating each new version and introducing it into systems already in operation and new systems.
The share of each component in the total maintenance costs can vary significantly depending on the characteristics of the application domain and the life cycle of the specific software. For long-lived (~10 years), widely distributed (1,000—100,000 copies) software, the dominant costs are usually those of upgrading and refining program versions. Upgrade costs depend indirectly on the production run, due to the expansion of the conditions of use of the specific software and the increased flow of user requests for program development. The production run also indirectly affects requests for eliminating identified errors.
The costs of detecting and eliminating defects and errors in a program are determined by two factors: the costs of detecting each error and the costs of eliminating identified errors when forming the next version. The fewer errors there are in a program, the harder they are to detect, i.e., the higher the cost of identifying each error. The costs of eliminating errors and correcting programs are proportional to the number of defects identified between successive versions. Maintenance continuously requires costs for monitoring the state of program versions and ensuring their integrity. Based on experience, a widely distributed software suite of about 10^5 lines may require the continuous effort of a team of a dozen or more specialists to eliminate errors and correct versions and documentation.
The costs of improvement and upgrading of programs are close in content (but not in magnitude) to the costs of their initial development. Upgrading is usually carried out in stages. For each new reference version, only a certain part of the entire volume of the software is changed (developed). When a new version is introduced, this part can amount to 10—20% of the volume of the entire suite. The complexity of the relationships within the software means that the unit costs for the programs being changed during the upgrading of each version can be 2—3 times higher than the costs of creating programs of the same volume during initial design. This value depends on the extent to which the prospects for improving the software were provided for through standardization of the architecture and interfaces during systems design. The team of specialists who carried out the initial development is sometimes used to perform this work. Such an arrangement is most typical for unique, custom-built software. In these cases, the initial development and the upgrading are difficult to separate. For widely distributed software, a special team that did not carry out the initial development is often assigned to maintenance. In these cases, the development and maintenance stages, as well as the associated costs, can be separated more clearly.
The costs of distribution of each new version include the aggregate costs of producing copies of the software product, installing them on the target computers, and mastering them for normal operation. The costs of distributing versions during maintenance are practically proportional to the product of the number of versions and their production run. As a result of this
even relatively small costs per copy when introducing a new version can become significant over the life cycle of the entire series of versions of the software product.
Tooling environment resources for software maintenance determine a number of special tasks, for the performance of which separate systems and tools are needed. Separate environments for developing modifications and environments for testing corrections are necessary. The maintainer must help the customer create a maintenance plan and tooling environment. This requirement is critical when forming the maintenance environment and must be taken into account during the preliminary planning of the financial resources allocated for the maintenance and monitoring of the software product.
Potential tools that determine the cost of software maintenance are CASE tools. They should represent an interconnected set of tools that support all aspects of developing modifications and maintaining software (see standard ISO 14471). An interconnected set of CASE tools should be assembled in the form of a tooling environment for organizing and developing modifications, representing the methods, policies, guidelines, and standards that support maintenance work and that provide the tools for developing and modifying software products. The maintainer must also be provided with a tooling environment for testing the modified software product outside its operating environment.
Based on the analysis and evaluation of the calculated resource characteristics for maintenance, a final technical and economic justification of the need to maintain the specific software product should be carried out, and it should be determined:
whether it is advisable to continue the work of maintaining and monitoring the specific software product, or whether it should be discontinued due to insufficient specialist resources, time, or the high labor intensity of developing modifications;
if sufficient resources are available, whether market research should be conducted to determine the cost-effectiveness of creating the next version of the software product and bringing it to market;
whether the concept and requirements for modifications to versions of the software product, on the basis of which the expert assessments and cost calculations were carried out, are formalized fully and correctly enough, or whether they should be corrected and the analysis repeated with refined initial data;
whether it is possible to use ready-made reusable software components, in what volume relative to the size of the software suite, and whether it is cost-effective to use them in the specific version of the software product, or whether it is advisable to develop the entire project as a completely new one.
Часть 1 15. Maintenance and monitoring of software systems
Часть 2 15.4. Resources for Providing Maintenance and Monitoring of Software Systems
Comments