Run systems without test operation
Launching systems on a “cascade model” has such project stages as pre-project inspection, system development, test operation and industrial operation. At the discretion of the parties, it is allowed to detail the project into many sub-levels and, for example, use not as “system development”, but “development of technical specifications” and “programming in the development environment”. In any case, according to the model, the stages can be performed only sequentially and only after the completion of the previous stage.
Any stage to the customer of the system is worth the time, additional work of staff and financial costs, so I will present features according to which you can skip the test period from the life of the project.
The most important thing when skipping a stage is not to lose the quality of the product being developed. To do this, we analyze the quality requirements section in GOST R ISO / IEC 25010-215 . It presents the main characteristics of the quality of the system (software products):
')
The GOST presents a complete list of requirements, so the answer to each of them gives a complete picture of the feasibility and economic efficiency of the project without a test operation stage.
Functional suitability. At the stage of functional modeling (prior to the development of the system), the identified constraints are described, which must be classified by importance. “Critical remarks” (Category 1 in the figure) have the greatest weight, which implies the impossibility of using the proposed system or its part.
If there are no critical comments on the pre-project works, then most likely they will not be at the time of launch. In the case of adjustments with the emergence of critical requirements, followed by a revision of the stages, where you can include a test period.
The shortcomings of categories 2 and 3 can already be dealt with at the stage of industrial operation, provided there are sufficient resources to ensure simultaneous elimination of the comments.
Performance level A modular approach to developing programs and not only them, but everything else, greatly simplifies the launch of new systems. If I develop a quadrocopter, then using components with a detailed description of the technical characteristics of the electric motor, processor, antenna from the manufacturer, I can quickly build a device with a performance specification. The technician should be familiar with the vendor products, and the analyst should take into account the specifics of the project.
For example, 1: (Library of Standard Subsystems) is used in a large number of programs. Testing its performance does not make sense, since it has been repeatedly tested in actual operating conditions before your project. Moreover, to create a better manufacturer is unlikely to succeed.
Large modules of their own design or large-scale project require testing.
Compatibility. A comprehensive system by default provides for the operation of all subsystems. Patchwork requires an analysis of the compatibility of both software modules and hardware. Compatibility between programs , DBMS, web services, equipment that have not been used in your practice requires verification.
The convenience of use. If you go back to the identification of comments on the pre-project survey, then you will notice the presence of not only critical comments, but also “making inconvenience”. For example, the lack of a service for filling in amounts in a document is not critical, since you can always count on a calculator and make it manually.
Do not forget about the reverse side of the moon: the test period increases the burden on the employee working in the two systems (new and old), which causes even more inconvenience than manually entering the amount of the document.
Reliability. This is the ability of the system for a long time to maintain a working state. If we consider the automation project based on the 1C Enterprise 8 technology platform, then reliability is provided by a number of conditions:
From any vendor there are errors. I repeat, any. Whether it is a Toyota corporation with 350 thousand people, withdrawing its cars because of production errors, whether it is 1C platform, which releases an update to eliminate errors.
Mistakes are different, some fascinating :)
Architect 1c requires a professional and cost-effective solution. If a lot of operational documents are entered, then client-server version with server clustering, replications is required for reliability. If there are a lot of documents but few users, then client-file mode is enough.
There is no general rule for choosing a work option from the number of users; an analytical approach is required. If you put 10 users with different roles of a manager, salesman, cashier, storekeeper, etc., then the file option may be pulled, and if there are 10 cashiers, then the client-server option is unique. The analyst understands the process of competition for resources.
It should also be noted that any technical structure breaks down (I am writing this text against the background of news about the global failure of Megaphone), and reliability means, among other things, data persistence and architecture recovery speed.
In continuation of Example 1C, I note that in practice I do daily archiving. On the current working day there should be archives for the last 90 days, then 1 copy for each month.
Do I need to test reliability? If this is a complex architecture, then load testing is necessary up to the fall to determine the maximum system capability (the task is to drop the base).
Security If the protection of confidential information is acute, I strongly recommend to develop a technical task for access to the system and do not skip the test operation.
There are 2 ways to work with user permissions in the new system:
It is in the first case that it is possible to skip the test operation, but it should be borne in mind that many users will have “extra” information in access.
In addition to authorized access to information, it is necessary to solve general security issues (password cracking, copying data archives, etc.). These actions are configured by the operating system or ancillary software.
Accompanying and Portability.
The duration of the test period rarely exceeds a month. This is due to the large labor costs of staff. Economically not profitable.
I don’t find much connection between these definitions and test operation.
Analyze all the points described above, make a SWOT analysis and make a decision on expediency. But in any case, if you start without test operation, be sure to include this item in the risk register and describe the reaction to it .
You can get the risk register template by mail “doc@ingraf.su” with the topic “Risks”.
Any stage to the customer of the system is worth the time, additional work of staff and financial costs, so I will present features according to which you can skip the test period from the life of the project.
Requirements for the quality of the system / software products
The most important thing when skipping a stage is not to lose the quality of the product being developed. To do this, we analyze the quality requirements section in GOST R ISO / IEC 25010-215 . It presents the main characteristics of the quality of the system (software products):
')
- functional fitness
- performance level
- compatibility,
- usability,
- reliability,
- security
- maintainability
- portability.
The GOST presents a complete list of requirements, so the answer to each of them gives a complete picture of the feasibility and economic efficiency of the project without a test operation stage.
Functional suitability. At the stage of functional modeling (prior to the development of the system), the identified constraints are described, which must be classified by importance. “Critical remarks” (Category 1 in the figure) have the greatest weight, which implies the impossibility of using the proposed system or its part.
If there are no critical comments on the pre-project works, then most likely they will not be at the time of launch. In the case of adjustments with the emergence of critical requirements, followed by a revision of the stages, where you can include a test period.
The shortcomings of categories 2 and 3 can already be dealt with at the stage of industrial operation, provided there are sufficient resources to ensure simultaneous elimination of the comments.
Performance level A modular approach to developing programs and not only them, but everything else, greatly simplifies the launch of new systems. If I develop a quadrocopter, then using components with a detailed description of the technical characteristics of the electric motor, processor, antenna from the manufacturer, I can quickly build a device with a performance specification. The technician should be familiar with the vendor products, and the analyst should take into account the specifics of the project.
For example, 1: (Library of Standard Subsystems) is used in a large number of programs. Testing its performance does not make sense, since it has been repeatedly tested in actual operating conditions before your project. Moreover, to create a better manufacturer is unlikely to succeed.
Large modules of their own design or large-scale project require testing.
Compatibility. A comprehensive system by default provides for the operation of all subsystems. Patchwork requires an analysis of the compatibility of both software modules and hardware. Compatibility between programs , DBMS, web services, equipment that have not been used in your practice requires verification.
The convenience of use. If you go back to the identification of comments on the pre-project survey, then you will notice the presence of not only critical comments, but also “making inconvenience”. For example, the lack of a service for filling in amounts in a document is not critical, since you can always count on a calculator and make it manually.
Do not forget about the reverse side of the moon: the test period increases the burden on the employee working in the two systems (new and old), which causes even more inconvenience than manually entering the amount of the document.
Reliability. This is the ability of the system for a long time to maintain a working state. If we consider the automation project based on the 1C Enterprise 8 technology platform, then reliability is provided by a number of conditions:
- reliability of technological platforms 1C, DBMS (depends on developers).
- qualified building of technical and software system architecture.
- qualified setting.
From any vendor there are errors. I repeat, any. Whether it is a Toyota corporation with 350 thousand people, withdrawing its cars because of production errors, whether it is 1C platform, which releases an update to eliminate errors.
Mistakes are different, some fascinating :)
Architect 1c requires a professional and cost-effective solution. If a lot of operational documents are entered, then client-server version with server clustering, replications is required for reliability. If there are a lot of documents but few users, then client-file mode is enough.
There is no general rule for choosing a work option from the number of users; an analytical approach is required. If you put 10 users with different roles of a manager, salesman, cashier, storekeeper, etc., then the file option may be pulled, and if there are 10 cashiers, then the client-server option is unique. The analyst understands the process of competition for resources.
It should also be noted that any technical structure breaks down (I am writing this text against the background of news about the global failure of Megaphone), and reliability means, among other things, data persistence and architecture recovery speed.
In continuation of Example 1C, I note that in practice I do daily archiving. On the current working day there should be archives for the last 90 days, then 1 copy for each month.
Do I need to test reliability? If this is a complex architecture, then load testing is necessary up to the fall to determine the maximum system capability (the task is to drop the base).
Security If the protection of confidential information is acute, I strongly recommend to develop a technical task for access to the system and do not skip the test operation.
There are 2 ways to work with user permissions in the new system:
- “From more to less” - we give everyone full access, and after the steady state of the project we begin the procedure of restriction.
- “From smaller to larger” - we create the minimum necessary set of rights, and as we receive a request, we increase it.
It is in the first case that it is possible to skip the test operation, but it should be borne in mind that many users will have “extra” information in access.
In addition to authorized access to information, it is necessary to solve general security issues (password cracking, copying data archives, etc.). These actions are configured by the operating system or ancillary software.
Accompanying and Portability.
The duration of the test period rarely exceeds a month. This is due to the large labor costs of staff. Economically not profitable.
I don’t find much connection between these definitions and test operation.
Summary
Analyze all the points described above, make a SWOT analysis and make a decision on expediency. But in any case, if you start without test operation, be sure to include this item in the risk register and describe the reaction to it .
You can get the risk register template by mail “doc@ingraf.su” with the topic “Risks”.
Source: https://habr.com/ru/post/330154/
All Articles