June 3, 2017 at 21:16Starting systems without test operation
The launch of systems according to the “cascade model” has such stages of the project 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 execution of the steps is possible only sequentially and only after the completion of the previous step.
Any stage to the customer of the system costs time, additional staff work and financial costs, so I will present the 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 will analyze the quality requirements section in GOST R ISO / IEC 25010-215 . It provides the main characteristics of the quality of the system (software products):
The GOST provides a complete list of requirements, so the answer to each of them gives a complete idea of the feasibility and economic efficiency of the project without a test operation stage.
Functional suitability. At the stage of functional modeling (before the start of system development), the identified limitations are described, which must be classified according to their importance. “Critical remarks” (Category 1 in the figure) have the greatest weight, which imply the impossibility of using the proposed system or part of it.
If no critical comments were identified in the pre-design work, then most likely they will not be there at the time of launch. In the case of adjustments with critical requirements, a review of the steps will follow, where you can include a test period.
Deficiencies of categories 2 and 3 can already be addressed at the stage of industrial operation, provided that resources are sufficient to ensure the simultaneous elimination of comments.
Performance level.The modular approach to developing programs and not only them, but everything else, greatly simplifies the launch of new systems. If I am developing 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 TTX representation. The technical specialist should be familiar with the products of the vendors, and the analyst should take into account the features of the project.
For example, 1C: BSP (Library of Standard Subsystems) is used in a large number of programs. It does not make sense to test its performance, as it has been repeatedly tested in real operating conditions prior to your project. Moreover, creating a better manufacturer is unlikely to succeed.
Large in-house modules or a large-scale project require testing.
Compatibility. An integrated system by default provides for the operation of all subsystems. Patchwork requires analysis of compatibility of both software modules and hardware. Compatibility between programs , DBMS, web services, equipment that were not used in your practice requires verification.
Ease of use. If we return to the identification of comments on the pre-project examination, we can notice the presence of not only critical comments, but also “introducing inconvenience”. For example, the lack of a service for filling in amounts in a document is not critical, because you can always calculate on a calculator and enter manually.
Do not forget about the back of the moon: the test period increases the load on an employee working in 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 to maintain a working state for a long time. If we consider the automation project based on the technological platform "1C Enterprise 8", then reliability is ensured by a number of conditions:
From any vendor there are errors. I repeat, any. Be it a Toyota corporation with a population of 350 thousand people, recalling its cars due to manufacturing errors, be it the 1C platform that will issue an update to eliminate errors.
Mistakes are different, some fascinating :) From the architect 1c a professional and cost-effective solution is required. If a lot of operational documents are introduced, then for reliability, a client-server option with server clustering and replication is required. If there are a lot of documents, but few users, then client-file mode is enough.
There is no general rule for choosing an option for the number of users; an analytical approach is required. If you plant 10 users with different roles of manager, seller, cashier, storekeeper, etc., then it is possible to pull the file version, and if there are 10 cashiers, then definitely the client-server version. The analyst understands the process of competition for resources.
It should also be noted that any technical structure breaks down (I write this text against the background of news about the global failure of Megaphone), and reliability means, among other things, data persistence and architecture restoration 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 until the fall to determine the maximum system capability (the task is to drop the base).
Security. If the protection of confidential information is acute, then I strongly recommend that you develop a technical task for access to the system and not skip 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 access to "extra" information.
In addition to authorized access to information, it is necessary to solve general security issues (breaking the password, copying the data archive, etc.). These actions are configured by the operating system or auxiliary software.
Accompaniment and Tolerance.
The duration of the test period rarely exceeds a month. This is due to the high labor costs of staff. Not economically viable.
I do not find a big connection between these definitions and test operation.
Analyze all the points described above, make a SWOT analysis and decide on the feasibility. But in any case, if you run without test operation, be sure to include this item in the risk register and describe the reaction to it .
You can get a risk register template by mail "doc@ingraf.su" indicating the topic "Risks".
Any stage to the customer of the system costs time, additional staff work and financial costs, so I will present the features according to which you can skip the test period from the life of the project.
System / Software Product Quality Requirements
The most important thing when skipping a stage is not to lose the quality of the product being developed. To do this, we will analyze the quality requirements section in GOST R ISO / IEC 25010-215 . It provides the main characteristics of the quality of the system (software products):
- functional suitability
- performance level
- compatibility,
- ease of use
- reliability,
- security
- accompanyability
- portability.
The GOST provides a complete list of requirements, so the answer to each of them gives a complete idea of the feasibility and economic efficiency of the project without a test operation stage.
Functional suitability. At the stage of functional modeling (before the start of system development), the identified limitations are described, which must be classified according to their importance. “Critical remarks” (Category 1 in the figure) have the greatest weight, which imply the impossibility of using the proposed system or part of it.
If no critical comments were identified in the pre-design work, then most likely they will not be there at the time of launch. In the case of adjustments with critical requirements, a review of the steps will follow, where you can include a test period.
Deficiencies of categories 2 and 3 can already be addressed at the stage of industrial operation, provided that resources are sufficient to ensure the simultaneous elimination of comments.
Performance level.The modular approach to developing programs and not only them, but everything else, greatly simplifies the launch of new systems. If I am developing 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 TTX representation. The technical specialist should be familiar with the products of the vendors, and the analyst should take into account the features of the project.
For example, 1C: BSP (Library of Standard Subsystems) is used in a large number of programs. It does not make sense to test its performance, as it has been repeatedly tested in real operating conditions prior to your project. Moreover, creating a better manufacturer is unlikely to succeed.
Large in-house modules or a large-scale project require testing.
Compatibility. An integrated system by default provides for the operation of all subsystems. Patchwork requires analysis of compatibility of both software modules and hardware. Compatibility between programs , DBMS, web services, equipment that were not used in your practice requires verification.
Ease of use. If we return to the identification of comments on the pre-project examination, we can notice the presence of not only critical comments, but also “introducing inconvenience”. For example, the lack of a service for filling in amounts in a document is not critical, because you can always calculate on a calculator and enter manually.
Do not forget about the back of the moon: the test period increases the load on an employee working in 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 to maintain a working state for a long time. If we consider the automation project based on the technological platform "1C Enterprise 8", then reliability is ensured by a number of conditions:
- reliability of technological platforms 1C, DBMS (depends on developers).
- qualified construction of the technical and software architecture of the system.
- qualified setup.
From any vendor there are errors. I repeat, any. Be it a Toyota corporation with a population of 350 thousand people, recalling its cars due to manufacturing errors, be it the 1C platform that will issue an update to eliminate errors.
Mistakes are different, some fascinating :) From the architect 1c a professional and cost-effective solution is required. If a lot of operational documents are introduced, then for reliability, a client-server option with server clustering and replication is required. If there are a lot of documents, but few users, then client-file mode is enough.
There is no general rule for choosing an option for the number of users; an analytical approach is required. If you plant 10 users with different roles of manager, seller, cashier, storekeeper, etc., then it is possible to pull the file version, and if there are 10 cashiers, then definitely the client-server version. The analyst understands the process of competition for resources.
It should also be noted that any technical structure breaks down (I write this text against the background of news about the global failure of Megaphone), and reliability means, among other things, data persistence and architecture restoration 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 until the fall to determine the maximum system capability (the task is to drop the base).
Security. If the protection of confidential information is acute, then I strongly recommend that you develop a technical task for access to the system and not skip test operation.
There are 2 ways to work with user permissions in the new system:
- “From bigger to smaller” - we give everyone full access, and after the steady state of the project, we begin the restriction process.
- “From the smallest to the largest” - we create the minimum necessary set of rights, and as we receive the 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 access to "extra" information.
In addition to authorized access to information, it is necessary to solve general security issues (breaking the password, copying the data archive, etc.). These actions are configured by the operating system or auxiliary software.
Accompaniment and Tolerance.
The duration of the test period rarely exceeds a month. This is due to the high labor costs of staff. Not economically viable.
I do not find a big connection between these definitions and test operation.
Summary
Analyze all the points described above, make a SWOT analysis and decide on the feasibility. But in any case, if you run without test operation, be sure to include this item in the risk register and describe the reaction to it .
You can get a risk register template by mail "doc@ingraf.su" indicating the topic "Risks".